Networker's Guide. LAN- IWAN-Analyse in Hochleistungsnetzwerken

>>>

NEW TECH

Networker’s Guide

Unser Online-Tipp für noch mehr Wissen …

... aktuelles Fachwissen rund um die Uhr – zum Probelesen, Downloaden oder auch auf Papier.

www.InformIT.de

>>> NEW TECH

Networker’s Guide LAN-IWAN-Analyse in Hochleistungsnetzwerken FRANK R. WALTHER

eBook Die nicht autorisierte Weitergabe dieses eBooks an Dritte ist eine Verletzung des Urheberrechts!

Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. Die Informationen in diesem Produkt werden ohne Rücksicht auf einen eventuellen Patentschutz veröffentlicht. Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt. Bei der Zusammenstellung von Texten und Abbildungen wurde mit größter Sorgfalt vorgegangen. Trotzdem können Fehler nicht vollständig ausgeschlossen werden. Verlag, Herausgeber und Autoren können für fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Für Verbesserungsvorschläge und Hinweise auf Fehler sind Verlag und Herausgeber dankbar. Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien. Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulässig. Fast alle Hardware- und Softwarebezeichnungen, die in diesem Buch erwähnt werden, sind gleichzeitig auch eingetragene Warenzeichen oder sollten als solche betrachtet werden. Umwelthinweis: Dieses Buch wurde auf chlorfrei gebleichtem Papier gedruckt.

10 9 8 7 6 5 4 3 2 1 06 05 04 03

ISBN 3-8272-6502-9

© 2003 by Markt+Technik Verlag, ein Imprint der Pearson Education Deutschland GmbH, Martin-Kollar-Straße 10–12, D 81829 München/Germany Alle Rechte vorbehalten Coverkonzept: independent Medien-Design, Wiedenmayerstraße 16, 80538 München Coverlayout: Sabine Krohberger Coverfotografie: Claudia Fillmann Lektorat: Angelika Ritthaler, [email protected] Herstellung: Ulrike Hempel, [email protected] Satz: reemers publishing services gmbh, Krefeld (www.reemers.de) Druck und Verarbeitung: Bercker, Kevelaer Printed in Germany

Inhaltsübersicht

Vorwort

21

Kritik der LAN-Analyse und Wege aus dem Zeitmengen-Dilemma

23

Kapitel 1

Der aktuelle Stand der Dinge

25

Kapitel 2

LAN-Analyzer in der Kritik

33

Kapitel 3

LAN-Analyzer: Anmerkungen

93

Kapitel 4

LAN-Analyse: Neue Wege

103

Kapitel 5

TraceMagic

117

Teil II

LAN-Analyse in den OSI-Schichten 1 bis 7

165

Kapitel 6

OSI-Schichten 1 und 2

167

Kapitel 7

TCP/IP-Grundlagen

223

Kapitel 8

OSI-Schichten 3 und 4: TCP/IP

327

Kapitel 9

OSI-Schichten 5 und 7: Namensdienste

359

Teil I

Kapitel 10 OSI-Schicht 7: Anwendungen

393

Kapitel 11 TCP- und Applikations-Analyse

403

>>> NEW TECH

5

Teil III

Fallstudien zu den OSI-Schichten 1 bis 7

427

Kapitel 12 OSI-Schicht 7: Client/Server-Dialoge

429

Kapitel 13 OSI-Schicht 7: Fallstudie Windows 9x-Client

473

Kapitel 14 OSI-Schicht 7: Fallstudie Windows XP-Client

503

Kapitel 15 OSI-Schicht 7: Fallstudie Voice over IP

609

Kapitel 16 Schlusswort: Zeit ist Geld

663

Anhang

Internetadressen von Herstellern und Produkten

671

Stichwortverzeichnis

673

15 Fragen an den Autor

697

Der Autor über sich

701

6

>>> NEW TECH

Inhaltsverzeichnis

Teil I Kapitel 1

Vorwort

21

Kritik der LAN-Analyse und Wege aus dem Zeitmengen-Dilemma

23

Der aktuelle Stand der Dinge

25

1.1 1.1.1 1.1.2 1.1.3 1.2 1.2.1 1.2.2 1.3 1.4 1.5

25 25 26 26 27 27 27 28 28

1.6 1.7

Kapitel 2

Bisherige Veröffentlichungen und das vorliegende Werk 2000 – Networker’s Guide: Grundlagen der Analyse 2001 – Registry Guide: Grundlagen der Registry 2003 – das aktuelle Buch Schwerpunkt: »Das Netzwerk ist langsam« Die alte Krankheit ... da war sie wieder! »Langsam? Wieso? Wir haben doch Gigabit!?« Schwerpunkt: OSI Layer 1/Gigabit-Ethernet Schwerpunkt: OSI Layer 3-4: Routing und Transport (TCP/IP) Schwerpunkt: OSI Layer 5-7: Name Services (NetBIOS, WINS, DNS etc.) Schwerpunkt: OSI Layer 7: Application Layer (NCP, SMB, HTTP, VoIP etc.) Schwerpunkt: neue Analyse-Techniken, neue Werkzeuge, neue Organisationsformen

29 30 30

LAN-Analyzer in der Kritik

33

2.1 2.2 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.4 2.5

33 33 34 34 35 36 36 37 37

>>> NEW TECH

Der bisherige Stand der Technik Die Situation des Autors bei dieser Kritik Die US-Hersteller ... ... und ihre Programmierer ... und ihre Eigentümer ... und ihre Hilflosigkeit ... und ihre Verdienste Das Scheitern der LAN-Analyzer Online-Expertensysteme: keine Zeit für tief gehende Analyse

7

Inhaltsverzeichnis

2.6 2.7 2.8 2.8.1 2.8.2 2.8.3 2.9 2.9.1 2.9.2 2.9.3 2.9.4 2.10 2.10.1 2.10.2 2.10.3 2.11 2.11.1 2.11.2 2.11.3 2.11.4 2.11.5 2.11.6 2.11.7 2.11.8 2.12 2.12.1 2.12.2 2.12.3 2.13 2.13.1 2.13.2 2.13.3 2.13.4 2.13.5 2.13.6 2.13.7 2.13.8 2.13.9

8

Offline-Expertensysteme: immer nur eine Datei zur selben Zeit Das Problem: Wann (zu welcher Zeit) war der Fehler? Das Scheitern auf OSI Layer 1 = Physical-Layer Beispiel: Paket-Verdopplung durch Layer-3-Switches Beispiel: defekte Pakete mit korrekter Prüfsumme Wie kommt es zu solchen Analyzer-Fehlleistungen? Das Scheitern auf OSI Layer 2 = Data Link Layer Fehler in ATM-Netzen MAC = 000000:000000 – ein netter, kleiner Tick von Switches LLC bei SNA Unicast-Pakete werden zu Multicast-Paketen verfälscht Das Scheitern auf OSI Layer 3 = Network/Routing DHCP Client Configuration Unerkannte Verstümmelung von IP-Paketen Unentdeckte Routing- und Verbindungsfehler im WAN Das Scheitern auf OSI Layer 4 = Transport/Data Flow Control Verschiedene Typen von TCP Retransmissions TCP Retransmissions, die gar keine sind TCP-Reaktionen auf Layer-3-Ereignisse TCP Window Size = Zero TCP Window Size = 536/576 (und ähnliche Werte) TCP Maximum Segment Size = 536/576 (und ähnliche Werte) TCP Reset: Verbindungsabbruch. Aber welcher? TCP Ports: Aussagen über Applikationen insgesamt Das Scheitern auf OSI Layer 5/7 = Name Services Dateisuche via DNS: jahresbilanz.xls Script-Abwicklung via DNS: IFMEMBEROF.LOCAL.DE Suche nach Phantom-Namen, z.B. JSPNRMPTGSBSSDIR Das Scheitern auf OSI Layer 7 = Application Datei-Operationen: korrekt, aber wahnsinnig Diagnose durch Quantifizierung braucht Qualifizierung Get File Size: 3.000-mal pro Sekunde Read File: Endlosschleife mit 100% Netzlast Open File: Verstümmelung von Dateinamen Open File: Dateien werden gesucht, wo sie nicht hin gehören Applikations-Fehler im Zusammenhang mit Fehlern der Schichten 1–4 Anwenderaktionen werden falsch umgesetzt (Beispiel: SAP/R3) Voice over IP läuft nicht richtig: versteckte Fehler im WAN

37 38 39 40 40 41 41 42 43 43 43 44 44 45 46 48 48 49 50 51 52 53 53 54 55 55 58 59 61 61 61 63 64 65 67 69 70 72

>>> NEW TECH

Inhaltsverzeichnis

2.14 2.14.1 2.14.2 2.14.3 2.14.4 2.15 2.15.1 2.15.2 2.16 2.16.1 2.16.2 2.17 2.18 2.18.1 2.18.2 2.18.3 2.18.4 2.18.5

Kapitel 3

Das Scheitern beim Filtern Filter auf IP-Adressen Filter auf Textfolgen und Namen (NetBIOS, WINS, DNS etc.) Online-Filter versus Offline-Filter Online-Filter als Ersatz für beschränkte Offline-Filter Das Scheitern des Stichprobenprinzips Nicht gelöst: Das Problem »giga«-großer Datenmengen bzw. langer Aufzeichnungszeiträume Nicht gelöst: Das Problem nur spontan auftretender Fehler Das Scheitern bei Verifikations-Analysen Fragen bzw. Bedingungen für eine erfolgreiche Verifikation Hilfreich, aber bei Analyzern nicht vorhanden: ein »Gedächtnis« (Datenbank) Das Scheitern mangels Datenbanken Das Scheitern bei der Berichtsausgabe Wie es (leider) bei den LAN-Analyzern ist Wie stattdessen gearbeitet werden sollte (TraceMagic) Effizienz der Berichtsweitergabe = Effizienz der Ergebnisumsetzung Berichtswesen, Arbeitsteilung und -organisation LAN-Analyse als permanente Qualitätssicherung (proaktiv statt reaktiv)

LAN-Analyzer: Anmerkungen 3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.1.8 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6

>>> NEW TECH

Software-Analyzer LANdecoder32 (Triticom) Observer (Network Instruments) EtherPeek NX (WildPackets) Sniffer (NAI, vormals Network General) Surveyor (Shomiti-Finisar) Ethereal TcpDump NTOP Hardware-Analyzer Hardware-Hersteller begehrt TraceMagic-Code Agilent (Hewlett Packard) Acterna (Wavetech Wandel Goltermann) Shomiti-Finisar NetTool (Fluke) NetVCR (NikSun)

73 73 75 78 79 81 81 82 84 85 86 86 87 88 88 89 89 90 93 93 93 94 95 96 96 97 98 99 99 100 101 101 101 102 102

9

Inhaltsverzeichnis

Kapitel 4

LAN-Analyse: Neue Wege

103

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8

103 103 105 107 108 110 111

4.9 4.10 Kapitel 5

10

Wandel der LAN-Analyse Die wichtigsten Stationen aus zehn Jahren Die Ausbildung der LAN-Analysten Fehler in der Arbeitsteilung der Unternehmen Automatisierte Methoden in Dokumentation und Analyse Verteilung der Ergebnisdaten nach erfolgter Analyse Betriebliche Abläufe und ihre Forderungen an die Analyse Dauerhafte Qualitätssicherung über automatische Analyse-Verfahren Die Revisionsfähigkeit der Netzwerke Planbarkeit und Kostenrechnung

113 115 116

TraceMagic

117

5.1 5.2 5.2.1 5.2.2 5.2.3 5.2.4 5.3 5.4 5.4.1 5.4.2 5.4.3 5.4.4 5.5 5.6 5.6.1 5.6.2 5.6.3 5.6.4 5.6.5 5.6.6 5.6.7 5.6.8 5.6.9 5.7 5.7.1 5.7.2

117 118 118 119 120 121 122 124 125 126 127 128 130 131 131 132 132 133 134 134 134 136 136 136 137 138

Historische Entwicklung TraceMagic ist anders Gängige LAN-Analyzer und ihre Entwicklungs-Systematik TraceMagic und dessen Ansatz »von hinten herum« »Beschränkung aufs Wesentliche« versus »Perfektion total« TraceMagic in der Praxis und was Kunden sagen Das Konzept von TraceMagic Die vier Hauptmodule der TraceMagic-Analyse FilterMagic FindMagic HostMagic SpiderMagic Installation von TraceMagic Start von TraceMagic Das Startfenster (mit Abbruchmöglichkeit) Kleines INIT-Fenster Lizenz-Hinweis (Demo-Version oder Lizenz-Version) Prüfung der Datenbanken Benutzeranmeldung Auswahl des Analyzer-Trace-Formats Funktionswahl: Trace-Analyse oder Report-Viewer Datei-Auswahlmenü: Welche Traces sollen verarbeitet werden? Trace-Menü: Die zentrale Schaltstelle Der Start von SpiderMagic Auswahl der Unterfunktionen Start der SpiderMagic-Analyse mit TCP/IP

>>> NEW TECH

Inhaltsverzeichnis

5.7.3 5.7.4 5.7.5 5.7.6 5.7.7 5.7.8 5.7.9 5.7.10 5.7.11 5.7.12 5.8 5.8.1 5.8.2 5.8.3 5.9 5.9.1 5.9.2 5.9.3 5.10 5.11 5.12 5.12.1 5.12.2 5.12.3 5.12.4 5.12.5 5.13

Standardabfragen beim Start eines Analyse-Moduls Auswahl: Trace-Alias und Vorgangstitel Auswahl: Trace-Filter (ja oder nein) Auswahl: Größe der IP-Adresstabelle Vorbereitung der Report-Datenbanken (1) Auswahl: Größe der TCP History-Tabelle Auswahl: Trefferpakete in neue Trace-Datei schreiben? Auswahl: Trefferpakete in Text-Dekodierungen ausgeben? Vorbereitung der Report-Datenbanken (2) Auswahl: Endgültiger Start mit den gewählten Einstellungen Report-Dateien: Jeder Durchgang erhält sein eigenes Verzeichnis Die neu erzeugte Trace-Datei samt zugehörigem Event-Log Die Report-Datenbanken Die »reconstructed files« TraceMagic während der laufenden Analyse Trace-Analysis: Einfache Aktivitätsanzeige Trace-Analysis: Aufruf der Ergebnis-Datenbank Trace-Events: Aufruf des Event-Logs Trace-Reports: Abschlussreport-Dateien erzeugen Trace-History: Datenbank aller vergangenen Analyse-Vorgänge Die Report-Dateien und die Ergebnis-Datenbank TraceHistory: Summary TraceHistory: Details TraceHistory: EventFilter TraceHistory: Memo TraceHistory: History Database TraceEvents/EventFilter

138 138 139 141 142 142 143 145 146 146 147 147 148 148 149 149 150 150 154 155 155 155 155 159 160 160 161

Teil II

LAN-Analyse in den OSI-Schichten 1 bis 7

165

Kapitel 6

OSI-Schichten 1 und 2

167

6.1 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.1.6 6.1.7

167 168 168 169 170 171 172 172

>>> NEW TECH

Messtechnik und Analyse auf den OSI-Schichten 1 und 2 Was ist neu? Abschied von ATM, FDDI und Token-Ring im Campus-LAN Gigabit-Ethernet: Messungen unter Gigabit-Bedingungen Media-Splitter (TAP) statt Mirror-Port Geeignete Capture Engines für Gigabit-Messungen TcpDump auf dem Gigabit-Server Load Balancing

11

Inhaltsverzeichnis

6.2 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 6.2.8 Kapitel 7

12

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse Erdungsfehler: Switch defekt, Frames defekt Defekte Ethernet-Frames (1): Switch-Fehler Defekte Ethernet-Frames (2): Switch-Fehler Defekte Ethernet-Frames (3): Adapter-Fehler Switch-Fehler: Paketvervielfältigungen Switch-Fehler: Spanning Tree Topology Changes Switch-Fehler: Mirror-Port gibt Pakete falsch aus Switch-Fehler: Pfadtabellen reichen nicht aus

174 174 177 189 202 209 213 215 218

TCP/IP-Grundlagen

223

7.1 7.1.1 7.1.2 7.1.3 7.1.4 7.1.5 7.1.6 7.1.7 7.2 7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.2.6 7.3 7.4 7.4.1 7.4.2 7.4.3 7.4.4 7.4.5 7.4.6 7.4.7 7.4.8 7.4.9 7.5 7.5.1 7.5.2

223 223 225 225 228 229 230 230 230 231 232 233 235 239 241 241 242 242 243 244 246 248 248 248 249 249 250 251 251

Einführung: Was ist TCP/IP? Sie erben TCP, Inc. und führen es zum Erfolg Einrichtung von UDP wegen des Kostendrucks Sie expandieren und fusionieren mit der IP, Inc. ICMP meldet Störungen ARP und DNS für die richtige Adresse SNMP+RMON – Überwachung in Echtzeit Des Rätsels Lösung Die wichtigsten Protokolle der TCP/IP-Familie im Überblick Fundstellen in der WinNT Registry ARP – Address Resolution Protocol IP – Internet Protocol ICMP – Internet Control Message Protocol TCP – Transmission Control Protocol UDP – User Datagram Protocol Vorgehensweise Adress- und Namensauflösung Betriebsphase Die MAC-Addresse ist falsch zugewiesen (LAA) Die IP-Addresse ist falsch zugewiesen Die IP Subnet Mask stimmt nicht Der NetBIOS Name stimmt nicht Der DNS Name stimmt nicht Die IP-Adresse des DNS-Servers stimmt nicht Umgekehrte Namensabfragen bleiben erfolglos Fehler im Address Resolution Protocol (R/ARP) Routing-Fehler/Default Gateway Pakete laufen über andere Wege als vorgesehen Pakete werden von Routern verworfen

>>> NEW TECH

Inhaltsverzeichnis

7.5.3 7.5.4 7.6 7.6.1 7.6.2 7.6.3 7.6.4 7.6.5 7.6.6 7.6.7 7.6.8 7.7 7.7.1 7.7.2 7.7.3 7.7.4 7.7.5 7.7.6 7.7.7 7.7.8 7.7.9 7.7.10 7.7.11 7.7.12 7.8 7.8.1 7.8.2 7.8.3 7.8.4 7.8.5 7.8.6 7.8.7 7.8.8 7.8.9 7.8.10 7.9 7.10 7.10.1 7.10.2

>>> NEW TECH

Pakete laufen doppelt: Local Loop Router und ICMP Im Fokus des Analyzers: ICMP ICMP: »Destination Unreachable« ICMP: »Redirection – Gateway Address« ICMP: »Time Exceeded – TTL Expired« ICMP: »Time Exceeded – ReAssembly Timeout« ICMP: »Fragmentation Needed« ICMP: »Source Quench« ICMP: »Echo Request/Echo Reply« Grenzen von ICMP Im Fokus des Analyzers: IP IP: Version/Header Length IP: Type of Service (ToS) IP: Total Length IP: Fragment ID IP: Fragmentation Flags IP: Fragment Offset IP: Time To Live (TTL) IP: Protocol IP: Checksum IP: Source/Destination Address IP Expertendiagnose IP und NetBIOS Im Fokus des Analyzers: TCP Das Prinzip der TCP Data Flow Control TCP: Source/Destination Port TCP: Sequence/Acknowledge Number TCP: Data Offset TCP: Flags TCP: Window Size TCP: Checksum TCP: Urgent Pointer TCP: Maximum Segment Size (Option) TCP Expertendiagnose Im Fokus des Analyzers: UDP BOOTP/DHCP BOOTP – Bootstrap Protocol DHCP – Dynamic Host Configuration Protocol

253 254 254 255 257 258 259 260 261 261 262 263 264 265 266 270 273 275 275 278 279 279 283 284 286 287 294 298 304 306 310 313 314 314 315 316 318 318 319

13

Inhaltsverzeichnis

7.11 7.11.1 7.11.2 7.11.3 7.11.4 7.11.5 7.11.6 Kapitel 8

14

SNMP/RMON SNMP: Befehls- und Abfragesprache SNMP-over-IPX SNMP und CMIP SNMP Community String public/private RMON: Ferndiagnose/Verkehrsanalyse HS-RMON

324 324 325 325 325 326 326

OSI-Schichten 3 und 4: TCP/IP

327

8.1 Allgemeine (und fällige) Analyzer-Schelte 8.2 Verweis auf die anderen Kapitel 8.3 Vorgehensweise in diesem Kapitel 8.4 ICMP: Kurze Übersicht 8.5 IP: Fehler und Symptome 8.5.1 IP Corrupted Packet 8.5.2 IP Packet: MAC Multiple Tx/Duplicate IP Header 8.5.3 IP Packet: MAC Multicast/Broadcast 8.5.4 IP Version ungleich v4/v6 8.5.5 IP Header Length < 20 Octets 8.5.6 IP ToS / Type of Service 8.5.7 IP Total Length MAC Length 8.5.8 IP Packet ID = 0 8.5.9 IP Remote Route Change (IP Packet ID) 8.5.10 IP Packet ID / Duplicate ID / IP Local Loop 8.5.11 IP Packet ID / doppelt in verschiedenen Paketen 8.5.12 IP Fragmented Packets 8.5.13 IP Time-To-Live (TTL) / Erfassung aller Werte 8.5.14 IP Time-To-Live / TTL = 0 8.5.15 IP Local Loop/Both Packets: Before And After Hop 8.5.16 IP Local Loop/Single Packet: Only After Hop 8.5.17 IP Remote Route Change (TTL) 8.5.18 IP Remote Route Long Way (TTL) 8.5.19 IP Packet Ping-Pong (TTL) 8.5.20 IP Checksum 8.5.21 IP Source Address 8.5.22 IP Destination Address 8.5.23 IP Option / Header Extension 8.6 TCP: Fehler und Symptome 8.6.1 TCP Packet = Broadcast/Multicast 8.6.2 TCP Retransmission / ReTx SeqNo = PreTx SeqNo

327 329 329 329 330 330 331 331 332 332 332 332 333 333 335 336 336 337 337 337 338 338 339 339 340 340 340 342 342 342 343

>>> NEW TECH

Inhaltsverzeichnis

8.6.3 8.6.4 8.6.5 8.6.6 8.6.7 8.6.8 8.6.9 8.6.10 8.6.11 8.6.12 8.6.13 8.6.14 8.6.15 8.7 8.7.1 8.7.2 8.7.3 Kapitel 9

TCP Retransmission / ReTx SeqNo PreTx SeqNo TCP ReTx / Keep-Alive ReTransmission TCP No ReTx / IP Local Loop TCP No ReTx / IP Paketdreher TCP No ReTx / Header Duplicate TCP Missing Sequence TCP Flag(s) = SYN, ACK, PSH, URG, FIN, RST TCP Flag = RST/Abbruch TCP Flag = SYN/ReTx TCP Flag = FIN/ReTx TCP Flag = RST/ReTx TCP Window Size Low TCP MSS Low UDP: Name Services UDP Port 53/DNS UDP Port 137/WINS UDP Port 138/NetBIOS Datagram

343 344 345 345 346 346 347 347 348 349 349 350 352 354 355 356 357

OSI-Schichten 5 und 7: Namensdienste

359

9.1 9.1.1 9.1.2 9.1.3 9.1.4 9.1.5 9.1.6 9.1.7 9.1.8 9.1.9 9.1.10

360 361 362 362 364 365 366 368 372 372

9.1.11 9.2 9.2.1 9.2.2 9.2.3 9.2.4 9.2.5 9.2.6

>>> NEW TECH

Dateisuche per DNS Ergebnistabelle von TraceMagic/HostMagic DNS-Anfragen nach SLANT010DLAKBHT01 DNS-Anfragen nach SLANT010NETLOGONCONFIG.POL DNS-Anfragen nach SLANT011.Intern.sampleD.DE DNS-Anfragen nach SLANT011WADLE$BRIEFE01jhjfoo DNS-Anfragen nach JSPNRMPTGSBSSDIR DNS-Anfragen nach SLANT012LVSECHTSOFTWARELVS.DWX DNS-Anfragen nach SLANT012LVSECHTSOFTWAREWinlvs5.exe DNS-Anfragen nach MATYSDATAMAINLIST.DAT DNS-Anfragen nach SLANT011DOKUMENTEAbteilungenDExport TrogsangDiverseCretschmar.doc DNS-Anfragen nach SLANT011WADLE$BRIEFE01hjhATC.doc Script-Reparatur per DNS DNS-Namen werden in der NetWare-NDS gesucht Das Server-Login-Script als DNS-Anfrage DNS-Anfragen nach 49 DNS-Anfragen nach MS2MAILSOFTWAREGW55EPCLIENTUPDATE32.DLL DNS-Anfragen nach NDPS01 DNS-Anfragen nach SERVER

374 377 382 382 384 385 387 387 387

15

Inhaltsverzeichnis

9.2.7 9.2.8 9.2.9 9.3 9.3.1 9.3.2

DNS-Anfragen nach SERVERVOLUMEuser%username% DNS-Anfragen nach www.aol.co DNS-Anfragen nach www.kieser.com Telnet-Befehle per DNS DNS-Anfragen nach port, interfaces, configuration, admin DNS-Anfragen nach aim1.adsoftware.com.hook.com

Kapitel 10 OSI-Schicht 7: Anwendungen 10.1 10.1.1 10.1.2 10.1.3 10.1.4 10.1.5 10.2 10.2.1 10.2.2 10.2.3 10.2.4 10.2.5 10.2.6 10.2.7

393

Applikations-Analyse in diesem Buch TCP/IP und Appl. Layer Typische Fehler in Client/Server-Dialogen Fallstudie: Windows 95-Client Fallstudie: Windows XP-Client Fallstudie: Voice over IP und Provider-WAN TraceMagic: Funktionen und Einstellungen SpiderMagic: TCP/IP und Appl. Layer SpiderMagic: SMB (Windows, OS/2, Samba) SpiderMagic: NCP (Novell NetWare) SpiderMagic: HTTP (WWW: Internet, Intranet) SpiderMagic: Oracle – TNS SpiderMagic: Reconstructed Files (rc.files) SpiderMagic: VoIP (Voice over IP)

393 394 394 395 395 395 395 395 397 397 399 399 400 401

Kapitel 11 TCP- und Applikations-Analyse 11.1 11.1.1 11.1.2 11.1.3 11.1.4 11.2 11.2.1 11.2.2 11.2.3 11.2.4 11.2.5 11.2.6

16

387 388 388 389 389 390

403

TCP-Analyse als Teil der Applikations-Analyse TCP-Sitzungsverhalten der Anwendungen IP-Hosts: Teilnehmerverhalten Event-Log: Zusammenhänge und Abläufe Client-Zugriffe auf Server-Ressourcen: Erfolg und Misserfolg Praktisches Beispiel: ICA/Citrix Metaframe TCP-Port-Analysis (TraceStatistics, Tabelle 3) IP-Host-Analysis (TraceStatistics, Tabelle 4) Event-Log (Abläufe und Zusammenhänge) File Services: Nachweis aller Dateizugriffe SMB: Denied Resources (Zugriffsfehler) Name Services/Tabellen

403 404 404 404 404 405 405 412 418 421 423 423

>>> NEW TECH

Inhaltsverzeichnis

Teil III

Fallstudien zu den OSI-Schichten 1 bis 7

Kapitel 12 OSI-Schicht 7: Client/Server-Dialoge 12.1 12.1.1 12.1.2 12.2 12.2.1 12.2.2 12.2.3 12.2.4 12.2.5 12.2.6 12.2.7 12.3 12.3.1 12.3.2 12.3.3 12.3.4 12.3.5 12.3.6 12.3.7 12.4 12.4.1 12.4.2 12.4.3 12.4.4 12.4.5 12.4.6 12.4.7 12.5 12.5.1 12.5.2 12.5.3

TCP-Analyse als Teil der Applikations-Analyse TCP-Analyse als Basis der Applikations-Analyse Bedeutung einer ganzheitlichen, verknüpften Vorgehensweise Mutation von Dateinamen SAP Login Mutationen mit Sonderzeichen Interne Programmaufrufe des Clients als Server-Zugriffe Aus SAMPLE.TXT wird MCF-SAMPLE.TXT Net-Install sucht nach NiAgnt32.exe.Manifest (u.a.) Doppelt genäht hält besser: .EXE.PIF, .EXE.COM, .EXE.BAT ... Aus Dateien werden Verzeichnisse Suche nach Dateien, die es nicht gibt Überall ist foo Datei-Endung, aber kein Datei-Name %VARIABLEN% werden nicht aufgelöst Suche mit Datei-Verkettungen als Pfadangabe Verzeichnispfade mit Laufwerksbuchstaben Share-Pfade werden als Verzeichnispfade missbraucht UNC-Pfade werden als Verzeichnispfade missbraucht Endlosschleifen bei Dateizugriffen Endlossuche nach denselben Dateien Mehrfachlesen am selben Datei-Offset Extrem viele Zugriffe auf dieselbe Datei Extreme Wiederholung derselben Datei-Anfrage Extreme Suche nach DESKTOP.INI Endlose Dateisuche in wechselnden Verzeichnissen Extremes Öffnen/Lesen/Schließen von URL-Dateien WWW: Fehler bei HTTP-Zugriffen Einstellungen vor Beginn der Analyse Event-Log: Ablauf und Zusammenhänge Zugriffsstatistik: Nachweis aller Client-Requests und Server-Replies

Kapitel 13 OSI-Schicht 7: Fallstudie Windows 9x-Client 13.1 DHCP/ARP: Die neue IP-Adresse 13.1.1 DHCP: Request zum Bezug der eigenen IP-Adresse 13.1.2 ARP: zur Verifikation der IP-Adresse (»Gratuitious ARP«)

>>> NEW TECH

427 429 429 430 430 430 430 436 439 441 442 444 446 448 448 449 449 450 450 453 454 455 455 460 461 462 462 464 464 469 469 470 470 473 473 473 476

17

Inhaltsverzeichnis

13.2 13.2.1 13.2.2 13.2.3 13.2.4 13.3 13.3.1 13.3.2 13.3.3 13.3.4 13.4 13.4.1 13.4.2 13.5 13.5.1 13.5.2 13.6 13.6.1 13.6.2 13.6.3 13.6.4

WINS und GETDC WINS: Anmeldung am WINS-Server WINS: Abfragen der IP-Adresse des PDC SMB: GETDC-Request zur Bestätigung des PDC WINS: Abfragen der IP-Adresse des PDC SMB: NETLOGON OSI-Schicht 4: TCP-SYN OSI-Schicht 5: NetBIOS Session Request OSI-Schicht 7: SMB Verify Dialect OSI-Schicht 7: SMB Session Setup/Tree Connect SMB: Create (and More) Create – LSARPC Create – NETLOGON WINS-Refresh: irreguläre Wiederholungen Vermutung: Die WINS Lease Time ist zu kurz Messdaten: Filter auf WINS und DHCP TraceMagic: Auswertungen und Tabellen HostMagic/SingleHosts HostMagic/HostPairs HostMagic/TCP-Port Statistics SpiderMagic/TCP/IP-Analyse (Übersicht)

477 477 481 482 483 485 485 487 489 490 492 492 492 492 492 495 496 496 496 498 499

Kapitel 14 OSI-Schicht 7: Fallstudie Windows XP-Client 14.1 14.2 14.2.1 14.2.2 14.2.3 14.3 14.3.1 14.3.2 14.3.3 14.3.4 14.3.5 14.4 14.4.1 14.4.2

18

503

TraceMagic: Wann welches Modul? TraceMagic/HostMagic Einstellungen vor dem Start Ergebnisse: Device Detection (aktive Komponenten) Ergebnisse: Name Services (WINS, UDP-138, DNS) TraceMagic/SpiderMagic Einstellungen vor dem Start Einblicke während der laufenden Analyse TraceReport: Erzeugung der Ergebnistabellen des Analyse-Durchgangs TraceHistory: Datenbankfenster mit Sicht auf die Ergebnis-Dateien TraceStatistics: Die Datenbank der TCP/IP- und SMB-Statistiken TraceMagic/Event-Log und EventFilter Event-Filter auf NiAgnt32.exe GETDC-Befehle via Broadcast

504 505 505 512 514 520 520 529 533 534 538 570 572 574

>>> NEW TECH

Inhaltsverzeichnis

14.4.3 14.4.4 14.4.5 14.4.6 14.4.7 14.4.8 14.4.9 14.4.10 14.5

Client ruft TCP-SYN auf Port 445, Server gibt TCP-RST zurück; SMB-IPC-Zugriff über Port 139 Mehrfaches Lesen von 1.024 Bytes am selben Offset = 0 von LSARPC und SAMR Mehrfache Wiederholungen derselben sinnlosen DNS-Anfragen Server-Share wird als verstümmelte Datei-Anfrage missbraucht Zugriffe auf (und Abarbeiten von) NI5_FH.BAT und rc.files Zugriff auf die Datei NiApMgnt.dll – verzögert durch TCP-ReTx Verdacht: IP-Pakete treten in verdrehter Reihenfolge auf Router meldet: TTL = 0/Paket wurde verworfen Fazit der Fallstudie

Kapitel 15 OSI-Schicht 7: Fallstudie Voice over IP 15.1 15.2 15.2.1 15.2.2 15.2.3 15.2.4 15.3 15.3.1 15.3.2 15.3.3 15.3.4 15.3.5 15.3.6 15.3.7 15.3.8 15.4 15.4.1 15.4.2 15.4.3 15.4.4 15.5 15.6

Das VoIP-Projekt: Ausgangslage Voice over IP: RTP und RTCP TCP: Steuerdaten der VoIP-Endpunkte UDP und RTP (Real Time Protocol) UDP und RTCP (Real Time Control Protocol) UDP-Ports für RTP und RTCP Analyse in Castrop-Rauxel (Niederlassung) Der Messpunkt TCP Window Size/TCP Keep Alive SNMP mit Community public Laufzeitschwankungen: VoIP-Analyse im Observer MAC-Fehler (und vermeintliche TCP/IP-Fehler) IP-Pakete treffen in verdrehter Reihenfolge ein Untersuchung der TTL-Werte RTP-Paketverluste und RTCP-Meldungen dazu Analyse in der Unternehmenszentrale Der Messpunkt IP-Hosts und Paketdreher IP-Hosts und Verdopplungen von Paketen und IDs IP-Hosts und wechselnde TTL-Werte Fazit der WAN-Analyse im VoIP-Umfeld FilterMagic: Der Franzose in Castrop-Rauxel

Kapitel 16 Schlusswort: Zeit ist Geld 16.1 16.2 16.3

>>> NEW TECH

Zeitnah und online Analyse-Ergebnis: HTML-Projekt WWW: Projekt-Steuerung

576 578 584 586 587 600 601 604 607 609 609 610 610 610 610 611 611 611 612 612 613 615 628 631 631 636 636 636 637 639 649 650 663 663 663 664

19

Inhaltsverzeichnis

16.4 16.5 Anhang

20

TraceMagic: LAN-WAN Information Management Ausblick

664 668

Internetadressen von Herstellern und Produkten

671

Stichwortverzeichnis

673

15 Fragen an den Autor

697

Der Autor über sich

701

>>> NEW TECH

Vorwort

Zur großen Freude des Verfassers hat sich der Vorgänger dieses Buches, der Networker’s Guide (Markt+Technik, München 2000), zu einem Standardwerk entwickelt, das allgemein geschätzt wird sowohl für die theoretische Fundierung wie auch für die praktische Anleitung im Bereich der Netzwerk-Analyse. Weiterhin zur Freude des Verfassers wurde von vielen Lesern die fachliche Präzision, aber auch die unterhaltsame Vortragsart gelobt. Und da die Anfragen nicht enden woll(t)en, wann denn endlich das nächste Buch erscheinen werde, beantworten wir nunmehr alle Fragen dieser Art mit dem hier vorliegenden Werk. Wir versprechen nicht zu viel, wenn wir sagen: Mit diesem Buch und den darin beschriebenen Analyse-Methoden sprengen wir die Grenzen, die bisher allgemein der LAN-Analyse auferlegt waren. Der Leser erhält Einblick in Fehlerzusammenhänge, diagnostische Verfahren und therapeutische Vorgehensweisen, die bislang weltweit nicht bekannt waren und in diesem Buch erstmals veröffentlicht werden. Grundlage eines so weit reichenden Entwurfs ist die nunmehr zehnjährige Analyse-Erfahrung des Verfassers sowie der Umstand, dass er seit Januar 2002 nicht mehr nur sein Wissen publiziert, sondern auch die Software, mit der seine unbestrittenen Analyse-Erfolge möglich wurden: Hierbei handelt es sich um das LAN-Analyse-Expertensystem TraceMagic, das nicht mehr und nicht weniger als eine Revolution in der Analyse-Technik darstellt und die Maßstäbe der System-Analyse völlig neu definiert. Der Leser dieses Buches erfährt also nicht nur die theoretischen Grundlagen umfassender LAN- bzw. System-Analyse, sondern erhält auf der beiliegenden CD-ROM auch die Software selber (in einer wenig eingeschränkten TestVersion) sowie viele voll dokumentierte Fallbeispiele mit Analyse-Reports, die in den verschiedenen Kapiteln des Buches ausführlich erläutert werden. Somit ist das vorliegende Buch – wie schon der zuvor erschienene Networker’s Guide – sowohl für die strategische Planung wie auch für die unmittelbar praktische Umsetzung im Betrieb gedacht und geeignet. Bonn, Januar 2003 Frank R. Walther

>>> NEW TECH

21

Vorwort

Feedback Wie immer stehen wir unseren Lesern mit Rat und Tat zur Seite und ermuntern Sie daher ausdrücklich, sich bei Fragen an eine der angegebenen E-Mail-Adressen zu wenden. Scheuen Sie sich nicht, uns über Fehler zu informieren. Nur so können wir laufend an der Verbesserung unserer Bücher arbeiten. Aber auch Lob, Erfolgserlebnisse und Ihre Ergebnisse interessieren uns. Schreiben Sie uns unter [email protected], Ihre Mails werden sofort an den Autor weitergeleitet. Wenn Sie sich nur an den Autor wenden möchten, benutzen Sie die E-MailAdresse: [email protected].

22

>>> NEW TECH

Teil I Kritik der LAN-Analyse und Wege aus dem ZeitmengenDilemma

Kapitel 1 Kapitel 2 Kapitel 3 Kapitel 4 Kapitel 5

Der aktuelle Stand der Dinge LAN-Analyzer in der Kritik LAN-Analyzer: Anmerkungen LAN-Analyse: Neue Wege TraceMagic

25 33 93 103 117

Kapitel 1 Der aktuelle Stand der Dinge Um diese neue Auflage des Networker’s Guide einordnen zu können, soll das vorliegende Buch seinen Platz bekommen in der Reihe der Veröffentlichungen sowie der technischen Entwicklungen der letzten Zeit.

1.1 Bisherige Veröffentlichungen und das vorliegende Werk Der Verfasser dieses Buches publiziert seit dem Jahr 2000 Bücher aus dem Umfeld der Netzwerk- und System-Analyse. In den vergangenen Jahren sind erschienen: ■

■

Networker’s Guide LAN Analysis und Windows Troubleshooting München (Markt+Technik) 2000 Registry Guide Windows 2000 und Windows NT 4 München (Markt+Technik) 2001

Es soll kurz skizziert werden, welche Themen in den beiden vorigen Büchern behandelt wurden bzw. welches Wissen vorausgesetzt wird:

1.1.1

2000 – Networker’s Guide: Grundlagen der Analyse

Bis zum Jahr 2000 gab es in Deutschland keine Publikation, die eine LANAnalyse von Grund auf dargelegt hätte. Diese Lücke musste geschlossen werden. Der Networker’s Guide tut dies mit verschiedenen Schwerpunkten: ■ ■ ■ ■ ■ ■ ■ ■

Analyse des Physical-Layers (OSI Layer 1) Analyse des MAC Layers (OSI Layer 2a) bzw. Ethernet und Token-Ring Analyse des DLC-Layers (OSI Layer 2b) bzw. LLC und SNAP Analyse der TCP/IP-Protokoll-Familie (OSI Layer 3-4) Analyse der Name Services: NetBIOS, WINS, DNS Analyse der Geräte-Konfiguration: BOOTP, DHCP, WINS, Registry Analyse der Eigenheiten von MS Windows Analyse der MS Windows Registry (mit Blick auf die LAN/WAN)

>>> NEW TECH

25

Kapitel 1 • Der aktuelle Stand der Dinge

Die theoretischen Grundlagen werden fast durchgehend mit praktischen Beispielen anschaulich gemacht. Hierbei wird die praktische Handhabung sog. LAN-Analysatoren (»Analyzer«) gründlich in den Blick genommen. Der Networker’s Guide findet seine Grenzen bei Gigabit-Ethernet und Windows 2000, für die bei Redaktionsschluss 1999/2000 noch nicht genügend Erfahrungen vorlagen.

1.1.2

2001 – Registry Guide: Grundlagen der Registry

Der Networker’s Guide enthält einen Anhang mit über 300 dokumentierten Registry-Schlüsseln (Windows NT4) sowie mit der Erläuterung von RegistryEinstellungen im darstellenden Teil. Sowohl Reaktionen von Lesern, die lange bei Microsoft vergeblich nach vergleichbaren Fakten gesucht hatten, wie auch die Veränderungen in der Registry im Zuge der Migration von Windows NT4 zu Windows 2000 führten dazu, dass in der Folge der Registry Guide herausgebracht wurde. Mit dem Buch wurde die Software »RegCheck« ausgeliefert, die als Datenbank und Experten-System die Dokumentation der Registry sowie die Fehlersuche und Korrektur verschiedenster Einstellungen erlaubt. Im Kern erläutert das Buch umfangreich anhand ausführlicher Detailschilderungen die Unterschiede der Registry zwischen Windows NT4 und Windows 2000.

1.1.3

2003 – das aktuelle Buch

Waren die ersten beiden Bücher Grundlagen-Werke, so stellt das vorliegende Werk eine komplette Neuerung und einen massiven Durchbruch dar, ■ ■ ■

weil völlig neue Erkenntnisse und Methoden vorgestellt werden, weil wichtige Fehlernachweise hier überhaupt erstmals vorgelegt werden, weil weltweit nunmehr völlig neue Maßstäbe in der LAN/WAN- und System-Analyse gesetzt werden.

Dies geschieht vollständig auf Basis einer völlig neuen Methode, LAN-Analyse zu betreiben. Diese Methode beruht auf den Fähigkeiten des LAN-Analyse-Experten-Systems TraceMagic, das von Synapse:Networks (dem Unternehmen des Verfassers) entwickelt wurde. Eine Test-Version von TraceMagic ist auf der beiliegenden CD-ROM enthalten. Weiterhin liegen auf der CD-ROM viele Analyse-Reports bzw. Auswertungen von LAN/WAN-Messdaten, um die hier im Buch beschriebenen Störfälle anschaulich mit Fakten zu belegen bzw. nachvollziehbar zu machen.

26

>>> NEW TECH

Schwerpunkt: »Das Netzwerk ist langsam«

In Kapitel 2 wird ausführlich dargelegt, warum TraceMagic einer Revolution der LAN/WAN-Analyse und System-Analyse gleichkommt, mit welchen Funktionen es arbeitet, welche Bedeutung dies für EDV-Verantwortliche hat und welche Beiträge zu diesem Buch mit Analyse-Reports von TraceMagic geleistet werden konnten.

1.2 Schwerpunkt: »Das Netzwerk ist langsam« 1.2.1

Die alte Krankheit ... da war sie wieder!

Die Anwenderaussage »das Netzwerk ist langsam« ist so alt wie die Technik der Datennetze selber. So weit also nichts Neues. Inzwischen aber liegen fast flächendeckend Gigabit-Backbones in den Campus-Netzen (und darüber hinaus) und daher stellt sich die Frage: Wie kann das sein?

1.2.2

»Langsam? Wieso? Wir haben doch Gigabit!?«

In vielen Unternehmen wurden große Geldmittel aufgewendet, um ■ ■ ■

Gigabit-Backbones zu errichten, schnellere Anwender-PCs einzuführen, Hochleistungs-Server im Rechenzentrum aufzubauen

und alles, um – endlich!, endlich! – dem vermeintlich langsamen Datennetz zu annehmbaren Antwortzeiten zu verhelfen. Doch in vielen Fällen wurde nichts besser und in manchen Fällen wurden die Verhältnisse sogar noch schlechter. Wie kann das sein? Das vorliegende Buch gibt Antworten: ■ ■ ■

Ursachen für das vermeintlich »langsame Netzwerk« (= lange Antwortzeiten) Zuverlässige Nachweismethoden dieser Ursachen Wertvolle Hinweise zur Beseitigung dieser Zustände

Der Verfasser hat viele Unternehmen mit umfangreicher Diagnostik aus Migrations-Sackgassen geholfen, die sich zu finanziellen »Schwarzen Löchern« zu entwickeln drohten. Er weiß also, wovon er spricht. Der vorliegende Buch nun soll Ihnen wesentlich vermitteln, wie Sie sich schützen können. Es ist kein unabwendbares Schicksal, in dramatische Crashes und Störungen hineinzulaufen! Dieses Buch wird sich für Sie und Ihr Unternehmen unmittelbar bezahlt machen in dem Umfang, in welchem Sie es sich aneignen.

>>> NEW TECH

27

Kapitel 1 • Der aktuelle Stand der Dinge

1.3 Schwerpunkt: OSI Layer 1/Gigabit-Ethernet Der messtechnische Zugriff auf Gigabit-Backbones ist – je nach Gegebenheit – mal problemlos und schnell erreichbar, mal höchst kompliziert und aufwändig. Die Messtechnik hat sich unter den Bedingungen von Gigabit erkennbar verändert. Die Anforderungen an die Hard- und Software sind deutlich gestiegen und vor allem die sprichwörtlich GIGA(!)ntischen Datenmengen stellen die LAN-Analyse vor Herausforderungen, auf die noch bis vor kurzem (Anfang 2002) keine angemessenen Antworten vorlagen. Das vorliegende Buch wird folglich verschiedenen Fragen gründlich nachgehen: ■ ■ ■ ■ ■

Wie ist LAN-Analyse unter den Bedingungen von Gigabit möglich? Welche Voraussetzungen an Hard- und Software müssen erfüllt sein? Welche Produkte eignen sich, welche nicht? Welche Strategie muss insgesamt angewendet werden? Wie verhält es sich beim Einsatz von Load-Balancing-Verfahren?

So viel sei vorab gesagt: Die Zahl der tauglichen Analyse-Produkte hat sich im Gigabit-Bereich erheblich verringert. Ist noch bei Fast Ethernet eine sehr breite Produktpalette am Markt verfügbar (einschließlich zum Teil gut ausgereifter Shareware), so ist bei Gigabit Ethernet nur noch wenige Technik geeignet. Entsprechend wichtig ist es, hierüber ausreichend orientiert zu sein.

1.4 Schwerpunkt: OSI Layer 3-4: Routing und Transport (TCP/IP) Wer geglaubt hat, sein langjährig vertrauter LAN-Analyzer würde StandardProtokolle wie IP und TCP umfassend und gründlich der nötigen Untersuchung unterziehen, um auch versteckte Fehler zu erkennen, muss nunmehr zur Kenntnis nehmen, dass teilweise wenig mehr als mickrige Basics geliefert wurden. Insbesondere beim Nachweis versteckter Kommunikations-Fehler in WAN»Wolken« erweisen sich die gängigen Analyzer als weitgehend oder total unfähig, die geforderten Nachweise zu bringen. (Als »Wolke« wird ein für den Kunden großenteils unsichtbares Transit-Netz zwischen verschiedenen Betriebsstätten bezeichnet, eine »black box« also.) In einer Zeit weitweiter Verbund-Netze wird es immer dringlicher, Fehler auch in den von externen Dienstleistern (»Providern«) gestellten Transit-Netzen/ WANs zuverlässig nachzuweisen. Da nicht selten erhebliche Summen für den Betrieb der WAN-Verbindungen aufgewendet werden, ist es unmittelbar im Interesse der Unternehmen, ■ ■ ■

28

zu wissen, ob der Provider die vereinbarte Leistung erbringt, zu wissen, welche Fehler auf den/die Provider zurückzuführen sind, zu wissen, ob sie die Preise drücken oder auf Besserung bestehen sollen.

>>> NEW TECH

Schwerpunkt: OSI Layer 5-7: Name Services (NetBIOS, WINS, DNS etc.)

Die Möglichkeiten der herkömmlichen LAN-Analyzer sind oft schmerzlich begrenzt. Wichtige Nachweise können entweder gar nicht, oder nur unter hohem Aufwand erbracht werden (was folglich Zeitverlust und somit Betriebsverlust bedeutet). Hierfür werden noch prägnante Beispiele folgen. Der Verfasser dieses Buches verhehlt nicht, dass er über die meisten so genannten »Experten-Systeme« der gemeinhin bekannten LAN-Analyzer nur noch den Kopf schütteln kann. In kleinem Kreise ist er für seinen galligen Humor diesbezüglich bekannt. Dem Kunden jedoch bleibt das Lachen im Halse stecken: Wenn über Monate die Anwender klagen, dass die Applikationen über WAN-Leitungen langsam arbeiten und sogar oft abbrechen und wenn auch teure LAN-Analyzer keinen Befund dazu liefern (obwohl dies durch die Werbung der Hersteller in Aussicht gestellt wird), so bleibt kaum Spielraum für Humor. Dieses Buch wird zeigen, warum so viele Analyzer scheitern, wo ihre Defizite liegen, wie man es besser machen kann (und muss) und welchen Nutzen eine wirklich intelligente TCP/IP-Analyse stiften kann. Dieses Buch wird auch zeigen, dass eine tief greifende und breit angelegte TCP/ IP-Analyse kein Geheimnis ist. Mit den richtigen Werkzeugen können die bemängelten Defizite ausgeglichen werden.

1.5 Schwerpunkt: OSI Layer 5-7: Name Services (NetBIOS, WINS, DNS etc.) Wir sprachen schon davon: Auch in Zeiten von Gigabit Ethernet ist der Satz oft zu hören: »Das Netzwerk ist langsam.« Oft sind die Name Services daran beteiligt bzw. die Mechanismen zur Namensund Adressauflösung. Im Microsoft-Umfeld kommt es hierbei nicht selten zu geradezu bizarren Erscheinungen, die nach Art und Umfang geeignet wären, ein Abend füllendes Kabarettprogramm zu inspirieren. Auch hier wird das vorliegende Buch die Beweise nicht schuldig bleiben. Die Fehler (ob offen oder versteckt) werden nachgewiesen und Lösungswege aufgezeigt. Wie nicht anders zu erwarten, sind auch hier die entscheidenden Schritte nur möglich mit einer veränderten bzw. verbesserten Diagnostik. Wir werden aktuelle Beispiele liefern, auch aus Netzwerken mit Windows 2000 bzw. Windows XP (und nicht mehr nur Windows NT4 oder Windows 9x/ME). Die beiliegende CD-ROM enthält Beispiele mit Analyse-Reports, die zum Teil nachgerade groteske Szenarien dokumentieren. Sie werden also nicht nur wichtiges Wissen aufnehmen, sondern auch im Sinne guter Unterhaltung voll auf Ihre Kosten kommen!

>>> NEW TECH

29

Kapitel 1 • Der aktuelle Stand der Dinge

1.6 Schwerpunkt: OSI Layer 7: Application Layer (NCP, SMB, HTTP, VoIP etc.) Weitgehend kann heute davon ausgegangen werden, dass die Funktionen der Schichten 1-4 fehlerfrei arbeiten (OSI Layer 1-4). Daher rücken immer mehr Fehler aus folgenden Anwendungs-Bereichen in den Vordergrund: ■ ■ ■ ■

Konfigurationen von Clients, Servern, Routern etc. Client/Server-Dialoge mit den Plattform-Protokollen NCP, SMB, HTTP Applikationen und ihre Client/Server-Funktionen Echtzeit-Anwendungen wie Voice over IP (VoIP)

Hier fehlten bis vor kurzem fast vollständig leistungsfähige Analyse-Mittel. Gerade hier aber ist der diagnostische Zugriff besonders wichtig. Entsprechend wird dieses Buch zeigen, ■ ■ ■ ■

wie schnell und zügig Applikations-Fehler eingekreist werden können, wie bestimmte Fehler-Klassen zuverlässig nachgewiesen werden können, wie Applikations-Fehler manchmal von Konfigurationen abhängen, wie im einen oder anderen Fall Abhilfe aussehen könnte.

Für die Praxis sollten somit viele hilfreiche Hinweise und Handlungsanleitungen enthalten sein.

1.7 Schwerpunkt: neue Analyse-Techniken, neue Werkzeuge, neue Organisationsformen LAN-Analyse war bis vor kurzem ein Job für blasse Techniker, die nur zu Ostern oder an sonstigen Feiertagen ans Tageslicht kommen und ansonsten den zweifelhaften Genuss haben, als ebenso liebenswerte wie verschrobene Spinner angesehen zu werden. LAN-Analyse war bzw. ist im Auge des unbefangenen Betrachters eine Geheimwissenschaft, obskur, entrückt und nur wenigen Eingeweihten gegeben. Es dürfte kein Zufall sein, dass »System-Analyse« bzw. »LAN-Analyse« bis heute kein Ausbildungsberuf ist, obwohl es dringend geboten wäre, hier endlich zu geregelter Ausbildung von Nachwuchs zu kommen. In der Praxis bedeutet das heute: Die Qualität der Befunde und Aussagen, die über die so genannten LAN-Analyzer und Experten-Systeme geliefert werden, ist dermaßen mager, dass der Mangel nur über sehr erheblichen Einsatz an Personal und Zeit zu beheben war. Und das Personal wiederum hat wenig Analyse-Ausbildung genossen, kann selten tiefe Analyse-Praxis aufweisen, bleibt viel zu oft und viel zu lange im Stadium des ungesunden Halbwissens stehen. Unfreundlich gesagt: Analyse-Amateure haben bei Crash-Szenarien nicht selten den Druck auf ihren Schultern, Millionen schwere Betriebsausfallkosten abzuwenden.

30

>>> NEW TECH

Schwerpunkt: neue Analyse-Techniken, neue Werkzeuge, neue Organisationsformen

Abgesehen davon, dass Analyse unter den bekannten Bedingungen technisch völlig unbefriedigend ist, sind solche Zustände wenig sozialverträglich, weil sie auf übermäßig viele Überstunden sowie auf teilweise extreme seelische Belastung hinauslaufen (in extrem kurzer Zeit sollen komplexe Störfälle diagnostiziert und therapiert werden). Die solcherart entstehende Belastung der Techniker nimmt nicht selten Ausmaße an, die physisch und familiär schnell die Belastungsgrenzen erreicht. Die allseits zu beobachtende Folge ist, dass im Analyse-Bereich die Personalfluktuation ungewöhnlich hoch ist. Nur aber mit lang währender Personalkontinuität lässt sich das Wissen, die Handlungssicherheit bzw. das Urteilsvermögen aufbauen, das ein Unternehmen benötigt, um sich gegen Störfälle jedweder Art abzusichern. Es ist schnell einsichtig, dass ein so wichtiger Unternehmensprozess wie »Qualitätssicherung« und »Notfallentstörung« nicht auf dermaßen fragilem Boden errichtet werden kann, wie es in den vergangenen Jahrzehnten zwar versucht, viel zu oft aber nicht geschafft wurde. Wir benötigen also nicht nur einen Wechsel in den Analyse-Werkzeugen, sondern auch einen Wechsel in der Arbeitsorganisation, Arbeitsvorbereitung und Arbeitsteilung. Was bislang zwei Jahrzehnte fehlte, ist nun neuerdings möglich: 1. LAN-Analyse als permanenter, kontinuierlicher Unternehmensprozess 2. Klar definierte Qualitätsprüfungen, feste Vorgaben, feste Reaktionsweisen 3. Klar definierte Benachrichtigungs-Strukturen und Berichtspflichten 4. Datenbank-gestützte Analyse-Prozesse 5. Volle Verifikationsfähigkeit gegenüber Dritten, z.B. Lieferanten 6. Volle Verifikationsfähigkeit bei Folgemessungen (»Ist der Fehler weg?«) 7. Schaffung klarer Faktenbasis durch automatische Reports 8. Vermeidung des »Schwarze-Peter-Spiels« durch klare Faktenbasis 9. Planbarkeit permanenter Qualitätskontrolle 10. Stichproben werden ersetzt durch Massen-Screening 11. Automatische Auswertungsmethoden erhöhen die Genauigkeit der Aussagen und senken zugleich die Kosten; außerdem wird Personal frei gesetzt, das bisher manuell diese Arbeiten zu leisten hatte (ohne es gleichwohl zu schaffen). 12. Unmittelbare wirtschaftliche bzw. finanzielle Gewinne durch verminderten Personaleinsatz, durch kürzere Reaktionszeiten, durch längere Vorwarnzeiten und Berücksichtigung dessen in der betrieblichen Kostenrechnung. Das alles ist unter dem Stichwort »Qualitätssicherung« abzuhandeln.

>>> NEW TECH

31

Kapitel 1 • Der aktuelle Stand der Dinge

Die bisherige Analyse-Technik hat auf organisatorische und wirtschaftliche Belange praktisch überhaupt keine Rücksicht genommen. In Kapitel 2 wird ausführlich dargelegt, welcher Art diese bisherigen Mängel waren, welche Voraussetzungen und Wirkungen diese Mängel haben (hatten) und wie sie nunmehr behoben werden können.

32

>>> NEW TECH

Kapitel 2 LAN-Analyzer in der Kritik Da die Inhalte dieses Buches fast vollständig auf Befunden der praktischen LAN-Analyse beruhen, müssen diese Werkzeuge der Fehlerdiagnostik ihrerseits bewertet werden, um wiederum zu verstehen, wie Fehlerbefunde im LANTroubleshooting zu Stande kommen bzw. wie sie einzuordnen sind.

2.1 Der bisherige Stand der Technik Ohne eine gründliche Bestandsaufnahme der bisherigen LAN-Analyse-Technik ist das ganze nachfolgende Buch in Aufbau und Inhalt nicht nachvollziehbar. Es soll gezeigt werden, ■ ■ ■

dass viele Probleme bislang überhaupt nicht erkannt werden konnten, warum diese Probleme nicht erkannt werden konnten, welche anderen Wege zu Diagnose und Therapie möglich sind.

Hierbei spielt die auf der CD-ROM dem Buch beiliegende Analyse-Software TraceMagic eine große Rolle. Diese Software wurde vom Verfasser entwickelt, um die wesentlichen Mängel der am Markt eingeführten LAN-Analyzer auszugleichen. Es geht also darum, zu erkennen, ■ ■

welche Leistungen von den bekannten LAN-Analyzern erbracht werden können (und welche eben nicht) und welche sonstigen Leistungen auf anderem Wege erbracht werden müssen, darunter unter anderem von der beiliegenden Software TraceMagic.

Hier spielt eine große Rolle, dass der Verfasser seit 1992 praktische LANAnalyse betreibt und ein Wissen angesammelt hat, das bei der Entwicklung von TraceMagic große Hilfe leistete.

2.2 Die Situation des Autors bei dieser Kritik Der Autor ist seines Wissens nach mit seiner selbstständigen Tätigkeit seit 1992 inzwischen der dienstälteste freischaffende LAN-Analyst Deutschlands.

>>> NEW TECH

33

Kapitel 2 • LAN-Analyzer in der Kritik

Er hat mit mehreren Analyzer-Herstellern immer wieder Gespräche über Konzept und Fähigkeiten der Analyzer gesprochen; er war bei einem Hersteller eines Hardware-Analyzers an der Entwicklung beteiligt (Siemens, K1100); er wurde noch in diesem Jahr von einem Marktführer für Hardware-Analyzer gefragt, ob er Analyse-Funktionen aus seinem TraceMagic-Projekt beizusteuern bereit wäre (der Hersteller will ungenannt bleiben). Er hat über die Jahre Programmierer und Eigentümer verschiedener US-Companies kennen gelernt, teilweise beraten und weiß somit, wovon er spricht. Die nachfolgende Kritik an den LAN-Analyzern sowie deren Herstellern bzw. Programmierern ist manchmal unüberhörbar sarkastisch. Das ist nicht böse gemeint, sondern schlicht die Folge des Umstandes, dass der Praktiker vor Ort, der nach Erfolg und per Tagessatz bezahlt wird, dringend darauf angewiesen ist, dass die verfügbare Diagnosetechnik auch die Fehler greifen kann, die der Kunde aktuell in seiner Datenkommunikation erleidet. Zu oft musste festgestellt werden, dass aktuelle Fehler nicht ansatzweise von den bekannten LANAnalyzern nachgewiesen werden konnten. Also blieb dem Verfasser letzten Endes nichts anderes übrig, als den Weg der Selbsthilfe zu beschreiten, was am Ende zur Entwicklung des Expertensystems TraceMagic führte (hierzu später mehr).

2.3 Die US-Hersteller ... 2.3.1

... und ihre Programmierer

Um das Ergebnis vorweg zu nehmen: Zu großen Teilen wissen die Programmierer sprichwörtlich nicht, was eigentlich Gegenstand ihrer Arbeit ist. Sie haben eben das Programmieren gelernt, nicht aber LAN-Analyse. Und der Software-Code ihrer so genannten LANAnalyzer sieht am Ende eben auch danach aus. Im Klartext: Das alles kann man nicht mehr ernst nehmen. Der Autor arbeitet seit 1996 mit eigenen Expertensystemen: ■ ■

Unter MS-DOS mit LANreport (nicht mehr aktuell) Unter Windows mit TraceMagic (Nachfolger von LANreport und Gegenstand dieses Buches; es ist auf der beiliegenden CD-ROM zu finden oder im Internet unter www.tracemagic.net)

Der Autor hat bis Sommer 2000 versucht, die US-Hersteller von der völligen Mangelhaftigkeit ihrer angeblichen »Expertensysteme« zu überzeugen – vergeblich. Oftmals kam der Kommentar: Das klinge zwar alles ganz nett, aber man verstünde nicht, wovon die Rede sei. Kein Wunder, waren die Gesprächspartner doch Programmierer, die von echter LAN-Analyse in ihrem Leben noch nichts gesehen und gehört hatten.

34

>>> NEW TECH

Die US-Hersteller ...

Diese Programmierer haben zum Teil noch niemals (!!) mit dem eigenen LANAnalyzer beim Kunden vor Ort eine echte Entstörung vorgenommen; sie haben keine Ahnung von den entscheidenden Betriebssystemen (MS-DOS, Windows, OS-2, Unix, NetWare, SNA, Apple) und deren Lebensäußerungen (IPX-SPX, NetBIOS, NetBEUI, NetBT, TCP/IP, AppleTalk etc.). Die Programmierer äußern freimütig: Sie seien eingestellt worden, weil sie jahrelange Erfahrung in Programmierung mit C++ haben, aber nicht, weil sie erfahrene LAN-Analysten wären. So sehen die Produkte dann auch aus: in weiten Teilen weltfremde Statistikmaschinen, die mit »Analyse« so viel zu tun haben wie ein Schwerlaster mit einer Melkmaschine. Die Programmierer äußern weiterhin freimütig, wie sie denn den ProgrammCode erarbeiten würden. Ganz einfach: Sie schreiben RFCs ab (RFC = Request For Comment; das sind die Standardisierungs-Dokumente der Internet-Protokolle). So sehen die Analyzer denn auch aus: veraltet, unwesentlich, an der Wirklichkeit heutiger Fehler vorbei gehend. Denn wenn ein RFC verabschiedet wird, ist er faktisch schon veraltet; und die in RFCs beschriebenen FehlerSzenarien haben mit der Realität so viel zu tun wie Märchen vom Klapperstorch mit moderner Geburtenverhütung.

2.3.2

... und ihre Eigentümer

Das folgende Beispiel darf streng genommen nicht für alle Hersteller herangezogen werden – und doch ist es symptomatisch und beispielhaft: Der Eigentümer eines der (selbst ernannten?) Marktführer bezeugte noch im Frühjahr 2002 im Verlaufe eines langen CeBIT-Abends dem Autor gegenüber, ■ ■

■

■

dass er seit langem mit seinem eigenen Analyzer keine echte Messung bzw. Entstörung mehr vor Ort durchgeführt habe; dass er aus Messdaten seines eignen Analyse-Produkts, die ihm im Laufe des Gesprächs per Laptop vorgelegt wurden, die enthaltenen Fehler nicht herausfinden könne, da das wesentlich von ihm selbst konzipierte Expertensystem dazu nicht in der Lage sei; dass er mit den Ergebnissen, die ihm sodann auf Basis der TraceMagic-Auswertungen vorgelegt wurden, nichts anfangen könne, da ihm die zu Grunde liegenden Sachverhalte – unter anderem der Allerweltsprotokolle TCP und SMB – nicht geläufig seien; dass er wohl in der Vergangenheit einiges falsch eingeschätzt und sein Produkt in die nicht ganz richtige Richtung entwickelt habe.

Könnte ein Armutszeugnis größer sein? Als der Autor dieses Buches dem armen Mann den Laptop samt Maus über den Tisch hin zuschob und ihn aufforderte, kraft des von ihm konzipierten Expertensystems den Kommunikationsfehler nachzuweisen, der in den Messdaten

>>> NEW TECH

35

Kapitel 2 • LAN-Analyzer in der Kritik

vorhanden sei, saß er völlig hilflos da und sagte wörtlich: Das ginge nicht. Sein Chefprogrammierer saß neben ihm und wurde ebenfalls ziemlich leise, weil auch er nur den Kopf schütteln konnte. Als beiden sodann vorgeführt wurde, wie die vom Autor stammende Software TraceMagic binnen weniger Minuten den kompletten Befund erbrachte, automatisch in Report-Dateien schrieb und auf den Bildschirm brachte, wurden sie sprichwörtlich blass: Diese Reaktion ist verbürgt durch die Aussage des Deutschland-Distributors, der beiden gegenüber saß und sie genau beobachten konnte. Die Gespräche mit anderen Herstellern waren zwar weniger ausführlich, weil Zeit oder Gelegenheit selten so umfassend gegeben waren, aber im Kern liefen sie immer gleich ab: Am Ende standen sich die Herren selber im Wege, weil sie ihr eigenes Scheitern einzugestehen hatten. Die Verkaufszahlen dieser Hersteller sprechen denn auch inzwischen für sich.

2.3.3

... und ihre Hilflosigkeit

Die Hilflosigkeit geht sogar so weit, dass der Autor dieses Buches mit seinem Unternehmen Synapse:Networks im Frühjahr 2002 nach zweimonatigen Verhandlungen mit einem führenden Hersteller von Hardware-Analyzern zur Überlassung von TraceMagic-Programmcode die Gespräche abbrach, weil seitens des US-Herstellers (genauer: seitens des Vertreters, der die Verhandlungen führte) jegliche Voraussetzungen fehlten, um überhaupt zu verstehen, worum es bei LAN-Analyse tatsächlich geht. Dem Betrachter erscheint das Ganze wie folgt: ■ ■ ■

Allgemein wird »Statistik« missverstanden als »Analyse«. Die grafische Umsetzung von Statistiken in Form von Kuchen- und Balkendiagrammen wird missverstanden als »Expertensystem«. Das Auswerten mikroskopisch kleiner Zeitfenster (wenige Sekunden oder Minuten aus einem Datenstrom von Stunden) wird für »Netzwerk-Analyse« gehalten.

Größer kann Hilflosigkeit schon kaum noch sein.

2.3.4

... und ihre Verdienste

Es soll nicht verkannt werden, dass die Hersteller der LAN-Analyzer ihre unbestrittenen Verdienste haben. Die Fähigkeit, die Datenpakete (»Frames«, »Packets«) von der Leitung zu lesen und auf Festplatte zu speichern (Capture-Files, Trace-Files), sowie die Fähigkeit, diese LAN-Packets mit der Protokoll-Dekodierung anzuzeigen, ist unverzichtbar und Grundlage jeder LAN-Analyse.

36

>>> NEW TECH

Das Scheitern der LAN-Analyzer

Gleichwohl ist den Herstellern vorzuwerfen, dass sie vom Konzept her über diese Fähigkeiten kaum nennenswert hinausgekommen sind. Entsprechend mangelt es beim Kunden an der Fähigkeit, kostspielige und gefährliche Fehler zu finden und zu beseitigen. Was also ist nun zu bemängeln?

2.4 Das Scheitern der LAN-Analyzer In vielen grundlegenden Kategorien scheitern die bekannten LAN-Analyzer weitgehend bis vollständig, was die Fähigkeit anbetrifft, Fehler in der Datenkommunikation sowie im Applikations-Verhalten von Clients und Servern zu erkennen. Die so genannten Expertensysteme verharren in einfachen Statistiken und das noch nicht einmal auf hohem Niveau. Im Folgenden wird benannt, worum es im Einzelnen geht.

2.5 Online-Expertensysteme: keine Zeit für tief gehende Analyse Die noch während der laufenden Messung arbeitenden Expertensysteme sind gewiss unverzichtbar und zum Teil durchaus gar nicht mal schlecht. Man darf nur nicht erwarten, dass sie etwas leisten, was sie nicht leisten können: nämlich Analyse. Was sie leisten können, ist: ■ ■ ■

Statistik Ereignisanzeige Überblick bei Mengenverhältnissen

Das ist gar nicht wenig, aber es ist eben nicht wirklich »Analyse« im Sinne eines Expertensystems. Der Name »Expertensystem« ist mehr als missverständlich, denn online (während die Messung noch läuft) ... ■ ■

... ist gar nicht genügend Zeit für eine umfassende Bewertung der Daten, ... ist nur wenige Mikrosekunden Zeit nach dem Eintreffen des aktuellen LAN-Paketes bis zum Eintreffen des darauf folgenden LAN-Paketes.

»Experten«-Analyse ist also online kaum möglich – schon gar nicht, wenn der Vergleich ansteht zu Offline-Systemen, die viel mehr Zeit haben, die Daten umfassend zu untersuchen und zu bewerten.

2.6 Offline-Expertensysteme: immer nur eine Datei zur selben Zeit Wenn denn nun bei der Online-Analyse zu wenig Zeit ist, um eineangemessene Analyse zu betreiben, bleibt nur der Weg zur Offline-Analyse. Offline-Analyse: Das bedeutet, dass die aufgezeichneten Messdaten (Capture-Files, Trace-Files) nachträglich ausgewertet werden.

>>> NEW TECH

37

Kapitel 2 • LAN-Analyzer in der Kritik

HINWEIS Nun aber stelle man sich vor: Sämtliche LAN-Analyzer der Welt sind nicht in der Lage, mehr als jeweils nur eine Trace-Datei zur selben Zeit auszuwerten!

Man muss beachten, von welchen Datenmengen wir im Bereich von Fast Ethernet (100 Mbps) und Gigabit-Ethernet (1000 Mbps) sprechen: Ethernet-Bitrate

Max. Pakete pro Sekunde

10 Mbps

14.400

100 Mbps = Fast Ethernet

144.000

1000 Mbps = Gigabit-Ethernet

1.440.000

Tabelle 2.1: Ethernet-Bitrate pro Sekunde vs. Paketrate pro Sekunde

In der Praxis sieht das so aus: Bei einer Messung im Gigabit-Backbone über zehn Stunden (etwa 08:00-18:00 Uhr) können mehre tausend Aufzeichnungs-Dateien auf die Festplatte des LAN-Analyzers geschrieben werden und jede einzelne dieser Dateien kann über 100.000 LAN-Pakete enthalten. Das Zeitfenster, das sich in jeder einzelnen dieser Dateien abbildet, beträgt bei Verkehrsspitzen (»bursts«) teilweise nur noch etwa 10–20 Sekunden. Wie soll LAN-Analyse betrieben werden mit einem Expertensystem, das allen Ernstes vom Anwender verlangt, ■ ■

... jede Trace-Datei einzeln über den DATEI ÖFFNEN...-Dialog einzuladen und zu untersuchen, ... am Ende also hunderte und tausende von Trace-Dateien dieser Art halbmanuell einzuladen und per Knopfdruck untersuchen zu lassen?

Wer soll das leisten? Wer soll die Zeit haben, sich über Stunden und Tage durch die Daten zu wühlen? Das ist unmöglich, zumal ein solch absurdes Verhalten noch zu ganz anderen Problemen führt:

2.7 Das Problem: Wann (zu welcher Zeit) war der Fehler? Die völlig unzureichende Methode, hunderte oder tausende von Trace-Dateien manuell geleitet der Untersuchung zuzuleiten, wird vollends absurd bei Berücksichtigung der folgenden Umstände: ■

38

Um den Aufwand annehmbar gering zu halten, muss aus der Vielzahl der Trace-Dateien die richtige herausgefunden werden. Der einzige Hinweis, der diese Auswahl ermöglicht, ist der Zeitstempel der Datei.

>>> NEW TECH

Das Scheitern auf OSI Layer 1 = Physical-Layer

■

■ ■

■

Dieses Auswahlverfahren setzt voraus, dass der Analyst (also der Mensch, der vor dem LAN-Analyzer sitzt) Kenntnis hat, um welche Uhrzeit ein Anwender über eine Störung Meldung gemacht hat. Nur schon eine Abweichung um 5–10 Minuten in der Aussage des PC-Benutzers kann bis zu 100 Trace-Dateien in die »engere« Auswahl bringen (!!). Selbst dann, wenn die Zeitangabe des PC-Benutzers sehr genau war, scheitert eine Analyse oft daran, dass zur angegebenen Zeit nur die vom PCAnwender sichtbare Wirkung des Fehlers wahrgenommen wurde; über die Uhrzeit der Fehlerursache ist damit aber nichts gesagt. Das bedeutet: Wenn nachmittags um 15:07 Uhr ein PC abstürzt, kann die Ursache morgens um 08:30 Uhr liegen, etwa im Zusammenhang mit BOOTP/DHCPKonfigurationen, WINS/DNS-Registrationen und Server/Domain-Anmeldungen.

Die bisher am Markt dominierenden LAN-Analyzer und ihre so genannten »Expertensysteme« bieten keinen (!!) Ansatz, einem solchen Szenario zu begegnen. Die einzige (!!) Software weltweit, die bei einem solchen Szenario zu einer umfassenden Auswertung kommt und die Ursachen samt Wirkungen sichtbar und auch in Bezug zueinander setzt, ist das vom Autor dieses Buches entwickelte Expertensystem TraceMagic. Das darf den Leser nicht verwundern, ist doch TraceMagic die einzige Software, ■ ■

... die in der Lage ist, hunderte oder tausende von Trace-Dateien automatisch und umfassend zu analysieren, ... die nicht von einem weltfremdem C++-Programmierer entwickelt wird, sondern von einem »alten Hasen« der praktischen LAN-Analyse.

Wenn sich Fehler nicht zeitlich eingrenzen lassen, zumal dann, wenn es sich um nur höchst sporadisch auftretende Fehler handelt, haben die herkömmlichen Analyzer keine Lösung zu bieten. Ihr Scheitern ist vollkommen. Dies war bzw. ist ein wesentlicher Grund, nach dem Networker’s Guide (Erstauflage April 2000) nunmehr das aktuelle Buch folgen zu lassen. Denn so konnte es nicht weiter gehen.

2.8 Das Scheitern auf OSI Layer 1 = Physical-Layer Jede LAN-Analyse setzt gedanklich bei den unteren Schichten an, um Fehler in der Physik bzw. der Hardware schnell zu erkennen oder schnell ausschließen zu können. Wenn jedoch hier schon Analyse-Fehler auftreten und wichtige LAN-Fehler nicht erkannt werden, kann man sich in den oberen OSI-Schichten sprichwörtlich dumm und dusselig suchen. Es folgen Beispiele hierzu.

>>> NEW TECH

39

Kapitel 2 • LAN-Analyzer in der Kritik

2.8.1

Beispiel: Paket-Verdopplung durch Layer-3-Switches

Im Jahre 2002 wurde in mehreren von Synapse:Networks bearbeiteten Störfällen mittels TraceMagic nachgewiesen, dass die Switches eines großen USHerstellers die Angewohnheit hatten, Pakete im LAN zu verdoppeln (Motto: eins rein, zwei raus). Sämtliche LAN-Analyzer, die seitens der Kunden, Switch-Hersteller und Dienstleister eingesetzt worden waren, ... ■ ■

... zeigten gar nichts an bzw. gaben keine Hinweise auf Fehler oder ... zeigten TCP Retransmissions (angeblich veranlasst vom Paketabsender).

Beide Angaben waren bzw. sind in einem solchen Falle einfach falsch. Unter den Analyzern, welche die Dopplung nicht erkannten, war beispielsweise ein »Product Of The Year 2002« (der Titel wurde von der US-Fachzeitschrift Network Magazine verliehen). Was soll man von einem Analyzer halten, der nicht erkennt, dass es sich eben nicht um TCP Retransmissions handelt (veranlasst von den sendenden Endgeräten), sondern um Mehrfach-Sendevorgänge aus dem Transmit-Buffer der Switches? Sowohl Techniker des Kunden (eine der größten deutschen Versicherungsgesellschaften) wie auch Techniker des Herstellers selber (einer der unstrittigen Weltmarktführer) waren jeweils nicht in der Lage gewesen, den Befund mittels ihrer LAN-Analyzer zu liefern, obwohl verschiedene Produkte eingesetzt worden waren. Das wirft in der Tat Fragen auf, welche die Analyzer-Hersteller nicht gerne hören. Denn es scheint offenkundig an Antworten zu mangeln. Ein Beispiel, das mit dem zusätzlichen Fehler der gleichzeitigen Verfälschung der Paket-Kopien zeigt, wie sich solches ereignen kann, ist in der Voice over IP Fallstudie ausführlich dokumentiert (diese Fallstudie ist im Layer-7-Teil des Buches zu finden).

2.8.2

Beispiel: defekte Pakete mit korrekter Prüfsumme

Mehrfach in den letzten Jahren konnte Synapse:Networks mit TraceMagic Fehler nachweisen, die sich wie folgt äußerten: Ein LAN-Switch verfälscht durchlaufende Ethernet-Pakete; diese Pakete werden einerseits verstümmelt, andererseits mit zufälligen Inhalten gestopft und verfälscht. Die marktüblichen Analyzer prüfen die Ethernet-Prüfsumme (FCS bzw. CRC) und sagen in diesem Falle: »Alles OK«, weil sie nicht in der Lage sind, die Verfälschungen zu erkennen.

40

>>> NEW TECH

Das Scheitern auf OSI Layer 2 = Data Link Layer

Um ein konkretes Beispiel zu geben: Switches eines großen US-Herstellers machten den Fehler, dass die SpeicherZuweisung für die LAN-Pakete fehlerhaft war; die Paketgrenzen wurden versetzt bzw. verschoben. Dadurch verteilten sich die Inhalte der eingehenden Pakete auf verschiedene ausgehende Pakete. Da die Switches jedoch davon selber nichts merkten, brachten sie die fehlerhaft aufgebauten Ethernet-Frames zur Versendung und berechneten die Ethernet-Prüfsumme, als ob nichts geschehen wäre. Ergebnis: Die gängigen LAN-Analyzer erkannten diese Fehler nicht, da ja eine korrekte Ethernet-Prüfsumme vorlag. Das Dumme daran nur war (bzw. ist), dass auch keine IP- oder TCP-Prüfsummen-Fehler angezeigt wurden (was ja ersatzweise ausreichen würde), da bei den betroffenen Paketen die IP- und TCP-Header nicht mehr an der korrekten Position saßen und daher nicht mehr erkennbar waren. Somit wurden auch auf diesem Wege diese Fehler nicht erkannt. Sicher: Bei manueller Durchsicht fallen solche Pakete früher oder später auf und dann sogar ziemlich deutlich. Die Frage ist nur: Wie soll man diese Pakete mal-eben-so finden, wenn 10 oder 50 Millionen Pakete mitgelesen wurden, aber der Fehler nur sporadisch seine Spuren hinterließ? Mit Stichproben kommt man in solchen Fällen nicht weiter. Man ist darauf angewiesen, dass eine automatische Untersuchung der Messdaten diese auffälligen bzw. fehlerhaften Pakete entdeckt. Das selbe Beispiel, auf das eben schon verwiesen wurde, zeigt auch hier, wie sich solche Fehler abspielen kann (siehe die Voice over IP Fallstudie im Layer-7Teil dieses Buches).

2.8.3

Wie kommt es zu solchen Analyzer-Fehlleistungen?

Die Frage also stellt sich: Wie können solch fundamental fehlgehenden Analysen, die nichts erkennen, zu Stande kommen? Die Antwort ist ganz einfach: weil die Programmierer solcherlei Ereignisse im ganzen Leben noch nie gesehen haben und weil in den StandardisierungsDokumenten (z.B. RFCs) keine Hinweise darauf zu finden sind.

2.9 Das Scheitern auf OSI Layer 2 = Data Link Layer Spezielle Fehler des so genannten MAC Layers bzw. Data Link Layers bedürfen ebenfalls genauerer Betrachtung.

>>> NEW TECH

41

Kapitel 2 • LAN-Analyzer in der Kritik

2.9.1

Fehler in ATM-Netzen

In vielen Fällen konnte der Verfasser Fehler in ATM-Netzwerken nachweisen, obwohl (weil?) viele andere vor ihm versucht hatten, mit ATM-Testern die Fehler in der »ATM-Wolke« aufzuspüren. Ohne das näher begründen zu wollen, hält der Verfasser die Eingebung, einen ATM-Fehler allein mit einem ATM-Tester erkennen zu wollen, für eine Schnapsidee. In den meisten Fällen sind sogar die ATM-Tester voll entbehrlich und LAN-Analyzer reichen aus, sofern man weiß, wonach man zu suchen hat, oder sofern ein Expertensystem die Messdaten nachträglich entsprechend auswerten und bewerten kann. ATM-Fehler lassen sich am zuverlässigsten erkennen, indem man links und rechts von der »ATM-Wolke« (also am LAN-Emulation-Client, welcher den Übergang von ATM zum LAN bildet) einen LAN-Analyzer den Datenverkehr mitlesen lässt, der von/zu dem ATM-Backbone fließt. Kennt man nunmehr genau die Arbeitsweise von ATM, lässt sich aus bestimmten, klar umrissenen Unregelmäßigkeiten im LAN-Verkehr exakt rückschließen auf Fehlerbedingungen im ATM-Netz – dies geht zum Teil bis hin zur Möglichkeit, sogar einzelne Details des Micro-Codes (der Firmware) als fehlerhaft erkennen zu können. Das setzt natürlich das entsprechende Wissen voraus und das setzt das richtige Werkzeug voraus. Der Verfasser dieses Buches hat zwei interessante Fälle hinter sich: ■

■

■

42

In einem Fall waren die Techniker des ATM-Herstellers (es war einer der Marktführer) acht Monate zugange, ohne den/die Fehler finden zu können. Dem Verfasser gelang es, innerhalb von nur vier Stunden (es war ein Vormittag) den kompletten Befund über ATM-Fehler samt ihren Ursachen zu liefern. Der Kunde war ein großes Banken-Rechenzentrum im Norddeutschen. In einem anderen Fall waren die Techniker des ATM-Herstellers (es war einer der anderen Marktführer) sogar zwölf Monate nicht in der Lage, den/ die Fehler zu finden. Auch hier dauerte es nur einen Vormittag, die komplette Diagnose zu stellen. Vertreter des Herstellers konnten nicht anders, als in einer der folgenden »Elefantenrunden« ihr Scheitern einzugestehen. Der Kunde war eine große öffentliche Kommunalverwaltung, die wegen der Störungen mehrfach zu ihrem Schaden in der Presse lächerlich gemacht wurde. In einem weiteren Fall wurde ein bundesweit arbeitendes ATM-WAN untersucht; die Techniker eines deutschen ATM-Ausstatters haben über Tage versucht, mit ATM-Testern eine Diagnose zu liefen. Sie konnten es nicht. Mit nur einem Tag Messung sowie tags drauf automatischer Auswertung mittels TraceMagic konnten die drei Minuten isoliert werden, in denen das ATM-Routing (auf Basis der LAN-Emulation) vollkommen zusammengebrochen war, und sämtliche relevanten Pakete und Meldungen konnten aufgezeigt werden.

>>> NEW TECH

Das Scheitern auf OSI Layer 2 = Data Link Layer

Alles nur Zufall? Wenn man in Abzug bringt, dass mancher Hobby-Analyst das Wissen nicht hatte (nicht haben konnte), das zur Diagnose nötig gewesen wäre, so bleibt der Befund: Sowohl die so genannten ATM-Tester wie auch die gängigen LAN-Analyzer bieten keine Handhabe, bestimmte ATM-Fehler in der LAN-Emulation und in der Hardware schnell und sicher zu erkennen – wie sonst ließen sich die oben dargestellten Erlebnisse erklären?

2.9.2

MAC = 000000:000000 – ein netter, kleiner Tick von Switches

Immer wieder mal (bei mindestens jedem dritten oder vierten Kunden) ist zu beobachten, dass Switches zwischendurch sporadisch mit der Absender-MACAdresse 0x 000000:000000 arbeiten – was falsch und schlicht verboten ist. Gängige Analyzer interessieren sich dafür überhaupt nicht und geben keine Warnmeldung ab. Das ist in der Tat erstaunlich, kann doch ein solches Fehlverhalten ein starker Hinweis auf interne Störungen des Switches sein.

2.9.3

LLC bei SNA

Es gibt Protokolle, die nicht mehr sonderlich berücksichtigt werden, darunter das SNA-Protokoll sowie das LLC-Protokoll. SNA-over-LLC ist in Deutschland immer noch bei Banken und Versicherungen verbreitet und es besteht oft auch keine ernstliche Veranlassung, dies zu ändern. Treten hier Fehler auf, kommt man mit den meisten Analyzern nicht ansatzweise zu einem tauglichen Ergebnis. Angesichts des Umstandes, dass Banken immer noch stark mit SNA arbeiten, und dass Buchungs-Systeme großer Bankgesellschaften äußerst empfindlich sind gegenüber Störungen und dass bedenkliche Verluste drohen können, ist es schwer nachvollziehbar, dass solche Mission Critical Applications in Betrieb genommen werden (bzw. in Betrieb gehalten werden), obwohl im Ernstfall praktisch keine Analyse-Möglichkeit besteht. Auf Grund dessen besitzt TraceMagic heute ein eigenes LLC/SNA-AnalyseModul.

2.9.4

Unicast-Pakete werden zu Multicast-Paketen verfälscht

Erst jüngst noch, im September 2002, ereignete sich folgender Störfall bei einem Kunden (einer nicht unbedeutenden Versicherungsgesellschaft): Ein Switch verfälscht die durchlaufenden Pakete in der sehr speziellen Form, dass MAC-Unicast-Adressen in MAC-Multicast-Adressen ausgetauscht werden (dies kann im ersten Oktett der Empfänger-MAC-Adresse geschehen, dies kann

>>> NEW TECH

43

Kapitel 2 • LAN-Analyzer in der Kritik

im Falle von Token-Ring aber auch im RIF-Header geschehen durch die Markierung »All Routes Broadcast« bzw. »Single Route Broadcast«). Der Kunde hat mit dem LAN-Analyzer von einem der Marktführer (nehmen wir diese Bezeichnung mal so hin) über Tage hinweg gemessen. Er hat zwar festgestellt, ziemlich viele Multicasts auf der Leitung zu haben; er hat aber nicht erkennen können, dass eine nachträgliche Verfälschung der Pakete stattfand, nachdem diese von den Absendern erst einmal auf die Leitung gebracht worden waren. Insbesondere konnte dieser so genannte »Analyzer« nicht den Kardinalfehler erkennen, dass TCP-Pakete als Multicasts unterwegs waren – und das zu tausenden! Da fragt man sich: Wie kann das denn nur angehen? Ganz einfach: In keinem RFC zu TCP ist die Rede davon, dass TCP-Pakete auch einmal Opfer einer Verfälschung der MAC-Adressen werden könnten! Darum ist die Folge eindeutig: Dann wird von den Programmierern der Analyzer ein solches Szenario eben auch nicht in die Expertensysteme integriert. Na prima, denkt man sich dann: Da sind wir ja bei Crashes gut »bedient«! Im vorliegenden Fall wurden ganze LAN-Segmente geflutet mit diesen Broadcasts/Multicasts und die Belastung der Switch-Buffer war durchaus nicht unerheblich.

2.10 Das Scheitern auf OSI Layer 3 = Network/Routing Vermeintlich ganz einfach sei die IP-Analyse, ist oft zu hören. Entweder ein IPPaket wird korrekt vom Router weitergeleitet oder eben nicht. Oder vielleicht ist mal eine Transitstrecke zwischen zwei Routern nicht in der Lage, die geforderte Paketgröße zu unterstützen. Gut: Dann eben sieht man sich die ICMPMeldungen der Router an und fertig. Viel mehr fällt oft nicht ein, wenn man über IP-Fehler nachdenkt, und die Analyzer sehen zu großen Teilen auch danach aus. Sehen wir uns Beispiele an, bei denen viele der herkömmlichen Analyzer Schwierigkeiten haben oder gar vollends scheitern (die folgenden Beispiele: ohne Anspruch auf Vollständigkeit).

2.10.1 DHCP Client Configuration Mancher Fehler hat seine Ursache darin, dass Clients nicht die gewünschte (erwartete) Konfiguration für ihre Teilnahme in der TCP/IP-Umgebung erhalten.

44

>>> NEW TECH

Das Scheitern auf OSI Layer 3 = Network/Routing

Hier geht es letztlich um folgende Möglichkeiten: ■ ■

Der DHCP-Server ist falsch eingerichtet und gibt daher falsche Werte an die Clients heraus. Es gibt mehrere konkurrierende DHCP-Server (und Router, die als DHCPRelais-Agent arbeiten) und das Resultat sind uneinheitliche Client-Einstellungen.

Es gibt noch weitere, allerdings eher exotische Möglichkeiten, so etwa DHCPServer-Rückgaben, die in der BOOTP/DHCP-Paketstruktur deformiert sind und daher vom Client nicht verstanden werden können; auch das wurde schon beobachtet. Gleich wie: Was hat das mit den gängigen Analyzern zu tun? Von einem fortgeschrittenen Analyzer ist zu erwarten, ■ ■ ■

dass er nicht nur einzelne DHCP-Pakete dekodiert, sondern ganze DHCPDialogabfolgen sichtbar macht; dass er den Katalog der TCP/IP-Werte und Domain-Namen etc. auflistet, die von jedem einzelnen DHCP-Server herausgegeben werden; dass er für jeden einzelnen IP-Host bzw. DHCP-Client nachweist, welche Einstellungen (in Sonderheit: welche IP-Adresse) zugewiesen wurden.

Das läuft darauf hinaus (Forderung), dass LAN-Analyzer nicht nur einzelne Pakete zu dekodieren hätten, sondern darüber hinaus ein Tabellenwerk zu pflegen hätten, das diese Daten aufnimmt zwecks beliebiger Abfrage durch den Analysten, der vor dem Bildschirm sitzt. Wer immer einen Analyzer besitzt, wird jetzt vermutlich feststellen, dass seine Diagnose-Software genau das alles nicht leistet. Und: Das Erstaunen ist groß, wieso man das eigentlich nicht schon immer vermisst hat. Nun, die Antwort dürfte lauten: Man hat sich schlicht an das gewöhnt, was über Jahre vorgesetzt wurde, und hat gelernt, auf Weiteres zu verzichten. Mit anderen Worten: Ein fortgeschrittener LAN-Analyzer sollte auch eine Netzwerk-Dokumentation liefern und dazu gehört in der IP-Umgebung unverzichtbar der Inhalt der DHCP-Dialoge, zugänglich über abfragbare Tabellen.

2.10.2 Unerkannte Verstümmelung von IP-Paketen Öfter, als man glauben möchte, treten Verstümmelungen von IP-Paketen auf, die von LAN-Analyzern nicht erkannt oder nicht hinreichend gewichtet werden. Wie kann das kommen? Die meisten Analyzer kontrollieren die Prüfsummen der verschiedenen Protokoll-Header: Ethernet CRC, IP Checksum, TCP Checksum. Normalerweise würde eine Paketverstümmelung mindestens Spuren in Form einer nicht stimmenden Prüfsumme auf Paketebene hinterlassen (Ethernet, Token-Ring, FDDI).

>>> NEW TECH

45

Kapitel 2 • LAN-Analyzer in der Kritik

Es kommt jedoch immer wieder mal vor, dass defekte Router bzw. Layer-3Switche durchlaufende Pakete deformieren und zwar dergestalt, dass die Paketinhalte verfälscht und diese verfälschten Inhalte mit einer »korrekten« MACCRC versehen werden. Das läuft so ab, dass im Hauptspeicher des Routers bzw. Layer-3-Switches Zuordnungen nicht stimmen und Inhalte verschiedener Pakete zusammen bzw. durcheinander gewürfelt werden. Dieses Sammelsurium wird sodann als vermeintliches IP-Paket zur Versendung an den MAC Layer weitergereicht, wo die MAC-Adressen vorgesetzt und die MAC-Checksum angefügt werden. Bei einem solchen Vorgang werden die fehlerhaften Inhalte durch eine in kurioser Weise »korrekten« MAC-Checksum »bestätigt«. Die meisten Analyzer würden zwar beim Decoding eines solchen einzelnen IPPakets feststellen, dass die IP-Prüfsumme nicht (mehr) stimmen kann. In der Betrachtung des MAC Layers bzw. Physical-Layers aber werden nur »gesunde« Pakete erkannt, da ja die MAC-CRC (bezogen auf den Paketinhalt) jeweils stimmt. Auf diese Weise ist des den LAN-Analyzern unmöglich, einen dergestalt vorliegenden Fehler im Router bzw. Layer-3-Switch zu erkennen. Der Verfasser ist in den letzten Jahren mehrfach mit solchen Fehlern konfrontiert gewesen und hat sich jedes Mal geärgert, dass die so teure Analyzer-Software das nicht erkannte (bei Produkten verschiedener Hersteller). Solche Befunde führen dann zu dem Ergebnis, dass eine neue Analyse-Software auf den Markt kommen musste, die auch solche Ereignisse aufdeckt bzw. automatisch erkennt.

2.10.3 Unentdeckte Routing- und Verbindungsfehler im WAN Das krasseste Beispiel kompletten Versagens in der IP-Analyse ist immer wieder in der Diagnose von Weitverkehrsnetzen (WANs) anzutreffen, mit denen verschiedene Betriebsstätten verbunden sind und bei denen die WAN-Verbindungen von einem externen Anbieter (Provider) gestellt werden. (Hier dürfen zu Recht alle bekannten Namen Revue passieren.) Bei vielen dieser WANs geschieht Folgendes: ■

■

46

Die WANs erbringen nicht die Leistung, für die der Kunde bezahlt. Entweder gibt es zu hohe Paketverluste, zu langsamen Datenfluss bzw. zu geringen Datendurchsatz oder es kommt immer wieder mal sporadisch zu Abbrüchen der Datensitzungen. Der oder die Provider sorgen dafür, dass der Kunde in seinem Campus-LAN keine ICMP-Meldungen seiner im WAN arbeitenden Router zu sehen bekommt: entweder durch Unterdrückung aller ICMP-Meldungen auf allen Routern oder durch Herausfiltern der ICMP-Meldungen beim Übergang vom WAN zum Kunden-LAN.

>>> NEW TECH

Das Scheitern auf OSI Layer 3 = Network/Routing

■

Der Kunde versucht sodann, bei Verdacht auf schlechte WAN-Leistung mit seinem LAN-Analyzer ICMP-Meldungen aufzuspüren, die Aufschluss geben würden. Da es aber diese Meldungen nicht gibt, tappt er weiter im Dunkeln.

Routing-Fehler in WANs werden entweder ausschließlich oder doch weit überwiegend von herkömmlichen Analyzern auf Basis von ICMP-Meldungen erkannt. Und wo es keine ICMP-Meldungen gibt, gibt's eben auch keine Diagnose. Allenfalls Datendurchsatz und Laufzeit können dann noch festgestellt bzw. protokolliert werden. That's it. Gleichwohl ist es möglich, viele oder gar die meisten der misslichen WANZustände auch ohne ICMP-Meldungen zu belegen und das sogar ziemlich umfangreich. Dabei muss man sich spezielle Effekte der Protokolle IP sowie TCP zunutze machen und von den Wirkungen auf die Ursachen zurück schließen. Wie das im Einzelnen geht, wird in einem der späteren Kapitel beschrieben werden. Im Kern jedoch kann jetzt schon festgestellt werden: diese Nachweise verlangen, dass der Analyzer ein extrem großes »Gedächtnis« in Form sehr umfangreicher Tabellen aufbaut, in denen bestimmte Merkmale der TCP- und IP-Protokolle abgelegt und verglichen werden und das für jeden einzelnen erkannten IP-Host, der in den Messdaten als IP-Absender erkennbar ist, sowie über den gesamten Zeitraum, der sich in den Messdaten abbildet. Genau diese Diagnosetechnik jedoch können herkömmliche Analyzer nicht anwenden, ■ ■ ■

weil sie nicht über die Fähigkeit verfügen, ausgedehnte Tabellen dieser Art zu führen, weil die bei Tabellen dieser Art erforderliche Ergebnisdarstellung bzw. Berichtsausgabe vollständig fehlt, weil allem Augenschein nach die Programmierer die Effekte, auf die es ankommt, gar nicht kennen.

Schon allein die Tatsache, dass die schlimmsten WAN-Fehler nicht durch Kontrolle des IP-Protokolls, sondern vielmehr durch Kontrolle des TCP-Protokolls (allein oder in Verbindung mit IP) zu erkennen sind, scheint bei den Programmierern der allgemein verbreiteten Analyzer noch nicht bekannt geworden zu sein. Somit fehlen den Kunden von WAN-Carriern allgemein die Möglichkeiten, die geheimen Fehler nachzuweisen, die letztlich doppelt auf ihre Kosten gehen: Die erforderliche Leistung (Durchsatz, Verfügbarkeit) ist möglicherweise nicht da und der solcherart überhöhte Mietpreis wird trotzdem Monat für Monat entrichtet. Der Verfasser hat mit seiner Software TraceMagic (siehe beiliegende CD-ROM) vor nicht langer Zeit in einem der in Bonn verbliebenen Bundesministerien einen Einsatz gehabt, als es darum ging, den Nachweis darüber zu führen, dass die Datenverbindung Bonn-Berlin nicht arbeitete, wie seitens des Kunden (des Ministeriums) gefordert und seitens des Providers stets neu zugesichert worden war (der Provider ist allgemein bekannt, jeder kann sich seinen Teil denken). >>> NEW TECH

47

Kapitel 2 • LAN-Analyzer in der Kritik

Nach Erbringung dieses Nachweises konnte das Ministerium schnell die notwendigen Korrekturen durchsetzen, auf die zuvor lange gewartet worden war. Inzwischen besitzt besagter WAN-Carrier selber die Analyse-Software TraceMagic. Über Zusammenhänge kann gegrübelt werden.

2.11 Das Scheitern auf OSI Layer 4 = Transport/Data Flow Control Jeder Leser sei aufgefordert, seinen LAN-Analyzer zu starten und nachzusehen, welche Ereignisse und Fehler im TCP-Bereich angezeigt werden. Wahrscheinlich lässt sich Folgendes auffinden: ■ ■ ■ ■ ■ ■ ■ ■ ■

TCP Retransmissions (Wiederholungsübertragungen) TCP Session Setup (TCP Synchronize mit folgenden Acknowledges) TCP Session Denial (Begehren nach Sitzungsaufbau wird abgelehnt) TCP Session Reset (eine laufende TCP-Sitzung wird abgebrochen) TCP SYN Flooding (Überflutung des Empfängers mit Sitzungsbegehren, etwa durch Code-Red-Virus) TCP Window Size Zero (Empfänger kann zurzeit keine Daten annehmen) TCP Keep Alive (eine laufende TCP-Sitzung soll vom Partner bestätigt werden) TCP Slow Response (die Antwort der Gegenstelle trifft mit auffälliger Verzögerung ein) TCP Idle Time (Leerlauf im Sitzungsdialog)

Diese Aufzählung ist sicherlich unvollständig und den Analyzern soll auch nicht Unrecht getan werden, aber im Wesentlichen handelt es sich bei den genannten Punkten um die Kernereignisse, die zu erkennen sie in der Lage sind. Werfen wir nun einen Blick auf TCP-Vorkommnisse, die allgemein keine oder nur geringe Berücksichtigung finden:

2.11.1 Verschiedene Typen von TCP Retransmissions Es ist schon erstaunlich: Es gibt eine Vielzahl von TCP Retransmissions, die zwar gemein haben, dass es sich um die Wiederholungsübertragung bereits gesendeter Daten handelt, die sich aber dadurch unterscheiden, dass wesentliche Merkmale voneinander abweichen – und dass diese verschiedenen Merkmale in aller Regel deutlichen Aufschluss über die spezifische Situation zulassen, in der die Wiederholungsübertragung veranlasst wird. Die meisten LAN-Analyzer werfen alle TCP Retransmissions sozusagen »in einen Topf« und gliedern nicht in die Unterscheidungen auf. Damit geht wichtige Erkenntnis verloren über das Kommunikationsstadium und die Verletzlichkeit der aktuell laufenden Dialoge.

48

>>> NEW TECH

Das Scheitern auf OSI Layer 4 = Transport/Data Flow Control

Die hier angedeuteten Abläufe sind in einem der späteren Kapitel mit Beispielen erklärt. Es soll hier jedoch eine kleine Vorausschau gegeben werden: Das TCP-Protokoll vermerkt mittels der so genannten TCP Sequence Numbers die Sendeposition (Offset) innerhalb des Datenstroms. Der Wert der aktuellen Sequence Number plus der Länge der im gegebenen Paket übergebenen Daten ergibt den Wert der Sequence Number des nächsten nachfolgenden Pakets (nächster Sende-Offset). In den meisten Fällen springt der Absender bei der TCP Retransmission zu einem der zuvor bereits verwendeten Offsets zurück und zwar entweder direkt veranlasst durch ausdrückliche Nachforderung der Gegenstelle oder indirekt veranlasst durch das Ausbleiben der Empfangsquittung der Gegenstelle. Dieses Verhalten ist typisch für uni-direktionale Dialogbeziehungen, will sagen: DateiÜbertragungen. In bestimmten Fällen jedoch springt die Wiederholung von Daten nicht zurück zu einem bereits zuvor verwendeten Offset, sondern zu einer Stelle im Sendestrom quasi »mitten drin«. Dieses Verhalten ist typisch für bi-direktionale Dialogbeziehungen, wie sie auftreten etwa bei Master-Slave-Verhältnissen der Inter Process Communication (IPC, eher bekannt im Unix-Umfeld) oder bei Vorgängen der Authorization/Authentication (etwa beim Anmelden eines WindowsClients am Domain-Server). Es ist offenkundig, ■ ■

dass Datei-Übertragungen allgemein weniger kritisch bzw. empfindlich sind gegenüber gelegentlichen Störeinflüssen, dass Authorization/Authentication sensible Prozesse sind, bei denen unter ungünstigen Bedingungen schon kleinere Störungen größere Folgen haben können.

Entsprechend wäre sehr zu wünschen, bei TCP Retransmission die entsprechende Aufschlüsselung bzw. Unterscheidung schon allein bezüglich dieser beiden Subtypen zu erhalten. Der werte Leser möge seinen LAN-Analyzer prüfen; mit einiger Aussicht auf Erfolg lautet das Ergebnis: die hier im Beispiel genannte Unterscheidung ist nicht auffindbar.

2.11.2 TCP Retransmissions, die gar keine sind In den letzten Jahren konnte öfters beobachtet werden, wie Layer-3-Switches eines besonderen Herstellers TCP/IP-Pakete, die auf der einen Seite hereinkamen, auf der anderen Seite vervielfältigten: Statt der Weitergabe nur eines Exemplars des TCP/IP-Pakets wurden mehrere Kopien davon noch zusätzlich auf die Leitung gebracht. Vergleiche mit verschiedenen Analyzern haben erbracht: Sie zeigten sämtlich »TCP Retransmission« an, da sie in mehreren, aufeinander folgenden TCPPaketen jeweils dieselbe TCP Sequence Number (Startposition der Nutzdaten >>> NEW TECH

49

Kapitel 2 • LAN-Analyzer in der Kritik

im Sendestrom) erkannten. Nicht einer der drei getesteten Analyzer (alle drei am Markt gut eingeführt) konnte erkennen, dass es sich hier um die Mehrfachübertragung aus dem Sende-Buffer eines Routers bzw. Switches handelte. Dass solche Deutungsfehler zu kolossalen Missdeutungen führen können und dass die zum Teil immense Flutung der Leitung mit Paketkopien nicht gestoppt werden konnte (in manchen Fällen von bis zu 30% des Gesamt-Traffics und mehr), da die Ursache nicht erkannt werden konnte – das alles kann für den Kunden zu verhängnisvoll falschen Handlungen führen. Das Erkennen einer Paketvervielfältigung durch einen Router und/oder Switch verlangt die Betrachtung von Merkmalen im IP-Protokoll, und genau diese kombinierte Sicht von Merkmalen der Protokolle TCP und IP scheint ein Hindernis zu sein, das für Programmierer bekannter Analyzer schwer zu nehmen ist. Die genauen Nachweistechniken zu diesen und ähnlichen Verhältnissen sind in den späteren Kapiteln zu finden.

2.11.3 TCP-Reaktionen auf Layer-3-Ereignisse Fortgeschrittene TCP-Treiber überprüfen den Erfolg der Paketzustellung via IP: Werden bei einem Datendialog mit einer bestimmten IP-Gegenstelle zu viele Fehler festgestellt, kann der TCP-Treiber verschiedene Maßnahmen einleiten, um Fehlertoleranz herzustellen bzw. um eine vor Abbruch gefährdete Sitzung noch zu retten. Diese zum Teil sehr speziellen TCP-Reaktionen erlauben bei gründlicher Betrachtung zum Teil sehr genaue Aussagen über die WAN-Strecken, die zwischen den TCP-Gegenstellen liegen. Nicht nur ist es möglich, für einzelne Sitzungen die Fehler und ggf. ihre Korrekturen zu erkennen; es ist vielmehr möglich, bei Betrachtung der Fehler innerhalb einer Matrix aller Verkehrsbeziehungen genau zu erkennen, welche WANVerbindungen von bestimmten Fehlern betroffen sind – und das, ohne dass ICMP-Meldungen etwaiger WAN-Router abgewartet werden müssten (die von den WAN-Providern oft unterdrückt werden). Auf diese Weise kann der Verdacht auf spezifische WAN-Fehler gegenüber nicht immer kooperationsfreudigen WAN-Carriern (Providern) klar erhärtet bzw. können die Ereignisse nachgewiesen und somit die Hilfsbereitschaft des Lieferanten befördert werden. Auf diese Abläufe wurde schon bei der Kritik zur IP-Analyse hingewiesen. Wenn es nun aber evident wichtig ist, versteckte IP-Fehler über TCP-Verhaltensweisen rückschließen zu können: Warum findet das in den bekannten LANAnalyzern nicht oder nur kaum statt?

50

>>> NEW TECH

Das Scheitern auf OSI Layer 4 = Transport/Data Flow Control

Diese Frage kann der Verfasser nur vage beantworten. Sicher ist, dass die Fähigkeit zu genauen Nachweisen dieser Art davon abhängt, ■ ■

dass große Tabellen geführt werden, in denen die Analyse-Software eine Vielzahl verbundener Merkmale nachhält, dass die Analyse nicht online während der Messung erfolgt (die kaum Zeit lässt für aufwändige Tabellen dieser Art), sondern offline in der nachträglichen Auswertung der aufgezeichneten Daten.

Es versteht sich von selbst, dass die mit diesem Buch auf CD-ROM gelieferte Test-Version von TraceMagic über die genannten Fähigkeiten verfügt.

2.11.4 TCP Window Size = Zero Die meisten (wenn nicht alle) am Markt eingeführten LAN-Analyzer erkennen und zeigen an, wenn ein TCP-Teilnehmer seiner Gegenstelle meldet, dass mindestens vorübergehend keine weiteren Daten angenommen werden können. Diese Meldung erfolgt über Bekanntgabe des verfügbaren Eingangs-Puffers: nämlich Window Size = 0 Bytes. In der Sprache von TCP wird der Empfangs-Puffer TCP Window Size genannt. Mit dieser Größenangabe wird der Gegenstelle angezeigt, wie viele Daten-Bytes höchstens gesendet werden dürfen und dass bis zum Erreichen dieser Menge nicht für jede Teilmenge eine Quittung des Empfängers zu erwarten ist (sofern nicht die Gegenstelle zwischendurch mit dem Push-Signal arbeitet). Im Grunde etabliert dieses Verhalten ein System von Sammelbestellung und Sammelquittung. Es verhindert Überlastung des Empfängers und gibt dem Absender die Gewissheit einer garantierten Annahme der verschickten Daten. Viele Analyzer nun begnügen sich damit, das Ereignis TCP Window Size = Zero anzuzeigen: Ach, wie niedlich. Es kann immer wieder mal vorkommen, dass ein Empfänger keine weiteren Daten annehmen kann, und daher ist es wichtig, unterscheiden zu können zwischen Allerweltsvorkommnissen dieser Art einerseits sowie ernsten Dialogstörungen andererseits. Um diese Unterscheidung treffen zu können, müssen folgende weitere Aussagen möglich sein: ■

Über welchen TCP-Port läuft der Dialog, der gerade von TCP Window Size = Zero betroffen ist? Das heißt: Beim Netzwerk-Drucken beispielsweise ist es völlig normal, dass der Printer zwischenzeitlich keine weiteren Seiten annehmen kann, weil er die zuvor empfangenen Seiten erst einmal ausdrucken muss. Das Signal TCP Window Size = Zero wird schlicht für das nötige Stop-And-Go-Verfahren eingesetzt.

>>> NEW TECH

51

Kapitel 2 • LAN-Analyzer in der Kritik

Welchen gewissermaßen historischen Vorlauf hat das Signal TCP Window Size = Zero? Das heißt: Wenn quasi aus heiterem Himmel (also bei zuvor angezeigter großer Window Size) auf WinSize = Zero gesprungen wird, so deutet alles auf einen Stop-And-Go-Mechanismus hin, entweder beim Drucken oder etwa auch bei Datenbank-Abfragen. Wenn aber der betroffene TCP-Teilnehmer von einem großen WinSize-Wert langsam, aber unablässig herabsteigt zu immer kleineren WinSize-Werten, so dürfte das vom Verfasser gerne »sterbender Schwan« genannte Szenario vorliegen: Ein TCP-Teilnehmer ist schlicht knapp an Ressourcen und bremst die Gegenstelle immer weiter aus. ■ Welche anderen Werte für die TCP Window Size werden verwendet – zwar größer Null, aber doch bedenklich? Es ergibt sicherlich doppelt wenig Sinn, wenn einerseits ein TCP-Teilnehmer seiner Gegenstelle ständig Puffergrößen von 11 oder 28 oder 41 Bytes bekannt gibt (was den Datendurchsatz mindert und »das Netzwerk langsam« macht) und wenn andererseits LAN-Analyzer das nicht anzeigen, weil ja die Window Size immerhin noch größer als Null ist! Es ist unmittelbar einleuchtend, dass es von hohem Interesse ist, zu erkennen, ob »der sterbende Schwan« vorliegt oder eben nur ein simpler »Stop-And-Go«Vorgang. ■

Die bekannten Analyzer verlangen aufwändige Handarbeit, um Fall für Fall den Nachweis zu führen. Das ist kaum durchführbar und also lässt man es bleiben. Die Folge jedoch ist, dass »das Netzwerk langsam« ist bzw. dass falsche Schlussfolgerungen gezogen und falsche Handlungen eingeleitet werden (vielleicht: demnächst Terabit statt Gigabit im Backbone?).

2.11.5 TCP Window Size = 536/576 (und ähnliche Werte) Ohne den detaillierten Beschreibungen nachfolgender Kapitel vorgreifen zu wollen, soll doch ein weiterer Sonderfall der TCP Window Size kurz aufgeführt werden. Es wurde oben bereits aufgeführt, dass TCP-Treiber die Dialoge auf Fehler hin überprüfen; und bei begründeter Annahme, eine bestimmte IP-Vermittlungsstrecke sei fehlerhaft, kann TCP Maßnahmen veranlassen, um Paketverluste auf der IP-Strecke zu vermeiden. Eine der Maßnahmen kann sein, die Gegenstelle zu zwingen, nur mit kleinen Paketen zu senden. Wie geschieht das? Nun, ganz einfach: Der hiesige TCPPartner teilt der fernen TCP-Gegenstelle mit, dass nur ein Minimum von 536

52

>>> NEW TECH

Das Scheitern auf OSI Layer 4 = Transport/Data Flow Control

Bytes Eingangs-Puffer frei wäre (Window Size) und schon bleibt dieser Gegenstelle nichts anderes übrig, als darauf einzugehen und auf die Versendung größerer Pakete zu verzichten. Dieses Verhalten spielt eine große Rolle, wenn IP-Transitstrecken große Pakete nicht zulassen und daher die beteiligten Router die zu großen Pakete verwerfen – immer eingedenk des Szenarios, dass ein WAN-Provider ggf. die Versendung oder Weitergabe von ICMP-Nachrichten durch seine Router unterdrückt hat. Auch hier lohnt ein Blick auf den Analyzer: Zeigt er's an? Wahrscheinlich nicht. Woher übrigens der etwas seltsam anmutende Wert von 536 kommt, wird in einem der TCP/IP-Kapitel erklärt.

2.11.6 TCP Maximum Segment Size = 536/576 (und ähnliche Werte) Hier gilt letztlich dasselbe wie bei entsprechenden Werten der TCP Window Size (siehe oben): Ein TCP-Teilnehmer möchte seine Gegenstelle dazu bewegen, mit kleinen Pakete zu senden und das vermutlich in Reaktion auf Paketverluste, da eine der WAN-Strecken große Pakete nicht unterstützt. Die genaue Erklärung des Hergangs erfolgt in einem der späteren Kapitel.

2.11.7 TCP Reset: Verbindungsabbruch. Aber welcher? Einen TCP Reset (abgekürzt: TCP-RST) zu erkennen und anzuzeigen, ist eine Grundübung und wird von jedem Analyzer beherrscht. Jedoch ist TCP-RST nicht gleich TCP-RST. Während noch ein TCP-RST in Folge eines TCP-SYN erkannt wird als Session Denied (einem TCP Synchronize folgt ein TCP Reset, was die Ablehnung eines Sitzungsbegehrens bedeutet), wird nicht unbedingt unterschieden zwischen harmlosen und ernsten Reset-Ereignissen. Es ist unbedingt erforderlich, in den TCP-RST-Statistiken die im Zuge von HTTP/WWW-Dialogen aufgetretenen Reset-Ereignisse gesondert auszuweisen, da die schlampige Programmierung von HTTP-Browsern (Client) und HTTPServern geradezu massenhaft zu TCP-RST-Ereignissen selbst bei »normalen« WWW-Zugriffen führt: Nach einem TCP-FIN (Final-Signal) wird nicht etwa mit einem TCP-FIN-ACK (Bestätigung) geantwortet, sondern mit einem TCPRST. Übrigens können auch andere Anwendungen dieses unplanmäßige Verhalten aufweisen; nur eben tritt es bei HTTP/WWW-Dialogen besonders häufig auf. Wird nicht mindestens zwischen WWW-Resets und allen sonstigen Resets unterschieden, ist in der heutigen Welt der massiven Internetnutzung auch in Büro-Netzwerken das Bild schnell verzerrt.

>>> NEW TECH

53

Kapitel 2 • LAN-Analyzer in der Kritik

Eine klare Aussage, ob denn nun zu viele Abbrüche da wären oder ob die Abbrüche letztlich unbedenklich wären, ist ohne eine solche Unterscheidung kaum möglich. Und wieder sei der Leser aufgefordert, seinen Analyzer zu befragen. Das Ergebnis könnte ernüchternd sein. Dann aber bedeutet das: Eine für sich genommen sinnvolle Anzeige ist mangels Anpassung an die Zeit des WWW mehr oder weniger wertlos geworden.

2.11.8 TCP Ports: Aussagen über Applikationen insgesamt Wenn schon TCP-Ereignisse von Analyzern »gesehen« werden, so würde sich ja anbieten, dass diese Ereignisse nicht nur je Dialog bzw. je Urheber verfolgt würden, sondern wenn Applikationen insgesamt betrachtet würden, also etwa: alle TCP-Ereignisse über Port 139 (OS-2, Windows, Samba: SMB) oder über Port 524 (Novell NetWare: NCP over TCP/IP). Mit einer solchen Betrachtung ließe sich schnell darüber Aufschluss gewinnen, welche Applikationen überhaupt insgesamt unter Störungen leiden (sofern diese Störungen Spuren in Form von TCP-Ereignissen hinterlassen). Eine solche netzwerkweite Sicht wird leider von den meisten Werkzeugen nicht unterstützt, da sie entweder alle Ereignisse auf den Urheber der Datenpakete beziehen oder aber dem Dialogpaar zuordnen, welches gerade aktuell eine TCP-Sitzung ausführt. Diese übliche Art der Zuordnung und Darstellung ist nicht falsch; sie verschafft aber keinen schnellen Überblick über die netzwerkweit am meisten auftretenden Fehler und erlaubt keine Klassifizierung der Applikationen in »gesund« und »ungesund«. Zeit aber ist Geld. Eine Analyse muss schnell die ersten Ergebnisse liefern, um die Zahl aller denkbaren Fehlermöglichkeiten möglichst plausibel nach wenigen Diagnoseschritten wirksam eingrenzen zu können. Wurde erst einmal eine Applikation als fehlerhaft bzw. fehleranfällig identifiziert, muss es danach möglich sein, das Ergebnis herunterzubrechen auf die einzelnen TCP/IP-Teilnehmer, die davon betroffen sind. Zu jedem dieser Teilnehmer müssen sodann weitere Aussagen bereit stehen zu praktisch allem, was dessen Sende- und Empfangsverhalten ausmacht. Auch muss möglich sein, Wechselwirkungen zwischen den verschiedensten Ereignissen und Fehlern zu erkennen, zum Beispiel auch (und gerade) dann, wenn der Teilnehmer über unterschiedliche Protokoll-Stapel arbeitet (z.B. NetBEUI, IPX, TCP/IP) und dieses Zusammenspiel nicht einwandfrei klappt. Es muss im Grunde egal sein, von welcher Seite man sich in der Analyse nähert: Am Ende müssen alle einzelnen Bestandteile des Fehlerbildes erfasst und dokumentiert sein, und die verschiedenen Wechselwirkungen bzw. UrsacheWirkungs-Verhältnisse müssen offen zu Tage liegen.

54

>>> NEW TECH

Das Scheitern auf OSI Layer 5/7 = Name Services

Das alles geht nicht, wenn man in einem Meer von Details schwimmt, ohne Übersicht zu erlangen. Dies führt zu dem Ansatz, dass – neben anderen tabellarischen Ergebnissen – die Applikationen anhand ihrer TCP-Ports netzwerkweit untersucht und übersichtlich dargestellt werden. Herkömmliche Analyzer leisten genau dieses nicht. Es ist kein Wunder, warum manch simpler Fehler immer noch zu viel Zeit für seine Erkennung verlangt.

2.12 Das Scheitern auf OSI Layer 5/7 = Name Services Das Kapitel »Name Services« gehört zu den spannendsten Bereichen überhaupt, die es im Bereich der LAN-Analyse gibt, und es ist eines der Kapitel des größten Scheiterns der bekannten Analyzer. Die nun folgenden Beispiele werden den Leser bizarr anmuten, und ... er hat Recht! Es gibt nichts, was es nicht gibt, und im Zweifel ist die große Welt der Windows-Netzwerke für keine Überraschung zu schade. Wenn Anwender klagen »das Netzwerk ist langsam«, dann mögen sie subjektiv empfinden, dass lange Antwortzeiten zu beklagen sind; aber der eigentliche physikalische Datentransport von A nach B ist gemeinhin tadellos und nicht zu beanstanden. Wenn missliche Verzögerungen eintreten, so kann das an völlig irrwitzigen Fehlern der File Services sowie der Name Services liegen. Fangen wir also an und betrachten wir Fehler der Name Services, die üble Folgen haben können und die von herkömmlichen Analyzern nur mit Mühe (oder gar nicht) in der ganzen Breite des Geschehens sichtbar bzw. nachvollziehbar gemacht werden.

2.12.1 Dateisuche via DNS: jahresbilanz.xls Ein immer wieder gern gesehener Pausenfüller ist der Versuch von (Windows-) Clients, eine auf verschiedenen File-Servern nicht gefundene Datei dann doch mal ersatzweise per DNS zu suchen. Das kann in folgendem, wirklich irren Ablauf enden. Das folgende Szenario wurde bei einem Kunden in der Nähe von Langenfeld (Rheinland) beobachtet; in abgewandelter Form sogar im Netzwerk eines großen Mineralöl-Konzerns (irgendwo in Deutschland). ■

■

Ein Client sucht verzweifelt nach jahresbilanz.xls. Jedoch kann keiner der angefragten File-Server helfen: Entweder haben sie die Datei, rücken sie aber nicht heraus; oder der Client sucht die falsche Datei; oder er sucht die richtige Datei am falschen Ort. Wer weiß das schon ... Der Client kommt nun nach vergeblicher Suche auf die Idee, zur phantasievollen Selbsthilfe zu greifen. Hier kommt das sonst gar nicht falsche Ansinnen von Microsoft zum Tragen, möglichst fehlertolerant auf solche

>>> NEW TECH

55

Kapitel 2 • LAN-Analyzer in der Kritik

■

■

■

■

■

■

■

■

■

56

Situationen zu reagieren. Auf welchem Wege auch immer kommt die DateiAnfrage nunmehr zum DNS-Treiber und der – nicht faul – schickt eine DNS-Anfrage an den Campus-DNS-Server: »Hallo, kennst Du die IPAdresse des Rechners mit dem Namen <jahresbilanz.xls> ?« Der Campus-DNS-Server kennt leider keine Domain namens .xls. Prompt vermutet er (wenn’s sich um einen Microsoft Windows NT 4 DNS-Server mit Default-Einstellungen handelt), dass es sich um eine neue Top-LevelDomain handeln müsse und dass sodann noch nichts verloren sei. Und schon sendet der Campus-DNS-Server die Anfrage an den nächsten zuständigen Internet-DNS-Server weiter; dies könnte der DNS-Server des Internetproviders sein. Dieser weiß auch nicht so recht weiter und empfiehlt freundlich, doch mal den DNS-Root-Server für den Buchstaben »x« in Austin, Texas, USA, zu befragen. Das tut der Campus-DNS-Server. Der Root-Server jedoch wurde inzwischen durch seine Admins angewiesen, solcherlei Idiotenanfragen schlicht zu ignorieren. Vielleicht blockt auch schon eine Firewall solche Anfragen ab, um die DNS-Server nicht zu belästigen. Das ist gut für den Root-Server, weil er sich folglich damit nicht herumzuplagen hat und es ist schlecht für den Campus-DNS-Server, weil er leider bis zum Timeout wartet – denn er muss bis zum Timeout warten, weil ja keine Antwort kommt. Nach Eintritt der Zeitüberschreitung (des Timeouts) sendet der CampusDNS-Server eine DNS-Antwort an den Client: »Schade, da konnte ich dir nicht helfen.« Beim DNS-Client jedoch, der ursprünglich mal nach jahresbilanz.xls suchte, ist inzwischen ebenfalls eine Zeitüberschreitung eingetreten und der UDPPort für die DNS-Anfrage nach jahresbilanz.xls wurde längst geschlossen. Schade auch! Daher sendet der DNS-Client beim Entreffen der DNS-ServerAbsage eine ICMP-Meldung: »ICMP: Port Unavailable« – was sagen soll: Der Client-Port, unter dem der DNS-Request gesendet worden war, ist nicht mehr aktiv. Das wurmt den Campus-DNS-Server gewaltig. Ist er doch dazu da, zu helfen! Und da er gemäß der Default-Einstellung in seiner Registry dazu neigt, bis zu fünf Retransmissions zu unternehmen, sendet er nunmehr die DNSAntwort (mit der Absage) bis zu fünfmal an genau den Port, dessen NichtExistenz ihm soeben via ICMP mitgeteilt wurde! Und jedes Mal sendet der Client dieselbe ICMP-Meldung erneut an den DNS-Server zurück. Dessen aber nicht genug. Der Client wartet ja immer noch darauf, jahresbilanz.xls zu finden und es kommt, verflucht noch mal, keine Antwort von diesem verflixten DNS-Server! Also schickt der Client die DNS-Anfrage nach jahresbilanz.xls erneut an den DNS-Server, der sich parallel noch gerade verzweifelt bemüht, die Meldung seines Scheiterns an den längst geschlossenen, älteren UDP-Port des Clients zu senden. Während der Campus-DNS-Server also weiter versucht, in Wiederholungen sein Scheitern mitzuteilen, erhält er den neuen DNS-Request nach jahresbilanz.xls. Anstatt nun zu erkennen, dass dieser Name nicht in eine IP-

>>> NEW TECH

Das Scheitern auf OSI Layer 5/7 = Name Services

■

■

Adresse auflösbar ist, schickt er den Request stur wieder hinaus ins Internet, und das, während er gerade doch noch verzweifelt bemüht ist, die Erfolglosigkeit dieser Suche dem Client mitzuteilen! Das heißt im Ergebnis: (A) DNS-Client und DNS-Server treiben sich selber gegenseitig in den Wahnsinn. (B) Das Ganze kann so weit gedeihen (zumal dann, wenn mehrere Clients nach Dateinamen suchen), dass selbst reguläre DNS-Anfragen nach simplen, lokalen DNS-Namen scheitern, weil der DNSServer schlicht überlastet ist. Klar: Beschäftigen sich doch Client und Server massiv gegenseitig, bis in die Blockade hinein. Am Ende kommt dann vom Anwender der Satz: »Das Netzwerk ist langsam ...!«

Diese heitere Episode, die immer wieder für einen Kabarettauftritt gut ist, wurde vom Verfasser selbst beobachtet und dem staunenden Publikum (= Kunden) dargeboten. Wer wollte sagen, LAN-Analyse würde keine Freude bereiten? Nun aber zurück zum Ernst der LAN-Analyse: Selbstverständlich sind die am Markt gängigen Analyzer in der Lage, DNSPakete zu dekodieren und den Inhalt auf dem Bildschirm anzuzeigen. Sie sind aber nicht in der Lage, derlei Wahnsinn übersichtlich zugänglich und in seiner Bedeutung schnell erfassbar zu machen. Schon gar nicht bieten sie sonderlich Hilfe, die Systematik solcher Fehlerabläufe hieb- und stichfest zu dokumentieren, indem die Zusammenhänge von File Services und Name Services über längere Zeiträume nachgewiesen werden. Äußerstenfalls kann der Anwender punktuell (also mit Stichproben) zum Ergebnis kommen, indem er einen Filter auf DNS und den Messpunkt unmittelbar vor den DNS-Server setzt: Dann erlaubt die manuelle Durchsicht der Messdaten das Erkennen solch bizarrer Abläufe (wenngleich die gelegentlich parallel laufenden WINS-Aktivitäten der Clients dadurch nicht mehr sichtbar sind, sofern der WINS-Server nicht mit dem DNS-Server identisch ist und wenngleich die voran gegangenen Anfragen über die File Services dann auch nicht mehr sichtbar sind). Verteilen sich diese Vorgänge aber innerhalb eines Gigabit-Datenstroms, weil der Messpunkt im Gigabit-Backbone lag, so ist der Zugang zu einem solchen Problem mit den Mitteln klassischer LAN-Analyzer praktisch kaum möglich: Denn wenn vielleicht gerade mal jedes zehntausendste Paket zu einer solchen DNS-Abfolge gehört und wenn sich die gesamte DNS-Abfolge auf 10 oder 20 Aufzeichnungs-Dateien verteilt, so ist kein manueller Zugang mehr möglich. Das führt hier – wie auch bei anderen Problemen – zu zwei Forderungen an die Analyzer: ■ ■

Eine tabellarische Auflistung aller Zugriffe und Misserfolge in den Namensdiensten ist unverzichtbar. Eine chronologische Ablaufdarstellung zur schnellen Übersicht muss ebenso gegeben sein.

>>> NEW TECH

57

Kapitel 2 • LAN-Analyzer in der Kritik

Diese Leistung wird von herkömmlichen Analyzern nicht erbracht; ihre Architektur gibt hierzu kaum eine Möglichkeit. Es bedarf kaum noch des Hinweises, dass TraceMagic über diese Funktionen bzw. Fähigkeiten verfügt.

2.12.2 Script-Abwicklung via DNS: IFMEMBEROF.LOCAL.DE Eine Variante des bereits oben durchgeführten Themas »Wie suche ich eine Datei via DNS« läuft wie folgt ab (beobachtet bei einem Kunden in Koblenz): ■ ■

■

■

■ ■

■ ■

■

■

Der Client lädt ein Script von einem seiner Server und versucht brav, die darin enthaltenen Anweisungen Zeile für Zeile abzuarbeiten. Der Script-Interpreter jedoch bleibt an einer Zeile hängen, die wegen eines dummen, kleinen Tippfehlers nicht deutbar ist, sagen wir: statt »if member of« steht da »ifmember of« (fehlendes Leerzeichen). Das Windows-Betriebssystem tut, was es doch immer gerne tut: helfen. Da der Script-Interpreter (auch »Parser« genannt) eine Fehlermeldung auslöst, springt das Betriebssystem hilfsweise ein und bietet sich an, einen Erfolg herbeizuführen. Somit wird die Textzeile aus dem Script an den DNS-Treiber übergeben. Dieser löscht alle untypischen Zeichen (Leerzeichen, Sonderzeichen) und schickt das Ganze als DNS-Anfrage an den Campus-DNS-Server. Dieser kennt leider keine Domain dieser Art und gibt eine Absage zurück. Daraufhin hängt der DNS-Client den lokalen Domain-Suffix hinten an die Text-Zeile (im Beispiel: .local.de) und schickt das Ganze erneut an den DNS-Server. Der DNS-Server erkennt zwar nunmehr den Domain-Namen, aber nicht den vermeintlichen Rechner. Der Client steht jetzt mit leeren Händen da: Die Abarbeitung der aktuellen Script-Zeile ist gescheitert. (Das war zuvor natürlich auch schon so, aber jetzt ist aus der subjektiven Sicht des Clients auch die letzte Hoffnung dahin!) Starten morgens um acht Uhr ein paar tausend Clients gleichzeitig und laden sie alle dasselbe fehlerhafte Script, so treiben sie nunmehr kollektiv den DNS-Server in den Wahnsinn (siehe obiges Beispiel: Dateisuche via DNS). Und schon wieder heißt es: »Das Netzwerk ist langsam.«

Auch diese Variante wurde vom Verfasser dieser Zeilen live miterlebt. Beim besagten Kunden in Koblenz konnte das Booten samt Login an einzelnen Arbeitsrechnern 10–15 Minuten dauern!

58

>>> NEW TECH

Das Scheitern auf OSI Layer 5/7 = Name Services

Jetzt zu den Analyzern in diesem Zusammenhang: Welcher Leser kann nachweisen, einen LAN-Analyzer zu besitzen, der den Zusammenhang zwischen DNS-Zugriffen und Script-Zeilen schnell und unkompliziert sichtbar macht? Vermutlich keiner. Da haben wir wieder einen Grund mehr, die beiliegende CD-ROM mit TraceMagic herauszuholen. Doch dazu später mehr. Ansonsten wird dieses Beispiel noch an anderer Stelle dieses Buches auftreten, weil die Verkettung von Fehlern so irrwitzig zahlreich und prägnant war, dass es ideal geeignet ist, die schlimmsten Fehler der Namensdienst-Treiber aufzuweisen. Außerdem dokumentiert dieses Beispiel sehr deutlich spezifische Probleme, die auftreten können, wenn die Netzwerk-Treiber von Microsoft sowie Novell gleichzeitig auf den Clients geladen sind und wenn diese Treiber in ihren Versions-Ständen nicht auf einander abgestimmt sind. Wir werden also dieses Beispiel zu späterem Zeitpunkt wieder besprechen und auf erstaunliche Effekte stoßen.

2.12.3 Suche nach Phantom-Namen, z.B. JSPNRMPTGSBSSDIR Wer hätte noch nie mit dem Analyzer Windows- bzw. NetBIOS-Namen gesehen, die ihm fremdartig vorkamen? Namen, die den deutlichen Eindruck machten, entweder sinnlos oder aus fremden Netzen zu sein? Aliens? Phantome? Dann zweifeln Sie nicht an sich! In der Windows- bzw. NetBIOS-Welt ist das ganz normal und kaum vermeidbar. (Erst ab Windows 2000 wird das langsam besser.) Wie in einem der späteren Kapitel noch nachzuweisen sein wird, haben die Name Services mit NetBIOS die Neigung, schwer kontrollierbar zu sein, da sich ständig fremde Namen einschleichen: sei es durch Laptops externer ServiceTechniker, die am Vortag noch im Netzwerk eines anderen Kunden arbeiteten; sei es durch fehlerhafte Scripts; sei es durch Internetkontakte und dergleichen mehr. Die näheren Zusammenhänge dieser NetBIOS-Abläufe werden weiter unten dargelegt werden. Hier geht es allein um die Tauglichkeit der LAN-Analyzer, in solchen Verhältnissen zu Ergebnissen zu kommen: Spezifische Fehler in den Name Services lassen sich nur sauber erkennen und am Ende sauber beheben, wenn ein komplettes Kompendium aller im Netzwerk auftauchenden NetBIOS- und DNS-Namen ausgegeben wird (Tabelle, Liste) – und wenn die Zusammenhänge bzw. Wechselwirkungen zwischen den verschiedenen Namensdiensten und Auflösungsmechanismen deutlich werden (Beispiel): ■ ■ ■

NetBIOS over LLC (mit SMB dabei NetBEUI genannt) NetBIOS over IPX NetBIOS over TCP/IP (NetBT)

>>> NEW TECH

59

Kapitel 2 • LAN-Analyzer in der Kritik

■ ■ ■ ■ ■ ■

Auflösungsversuche via Peer-to-Peer-Abfragen oder LAN-Broadcasts Auflösungsversuche via Master-Browser Auflösungsversuche via WINS Auflösungsversuche via DNS Auflösungsversuche via NetWare Bindery bzw. NetWare NDS Weitere Suchvarianten via IPX-SAP, SLP und dergleichen mehr

Allein schon die Häufigkeit, mit der nach Phantom-Namen gesucht wird, ist unerlässlich als Indikator für die Bewertung, ob es sich um ein vernachlässigenswertes Rand-Phänomen handelt oder ob ein schwer wiegendes MassenPhänomen vorliegt. ■

■

DNS: Der Administrator des DNS-Servers kann bei guter Arbeit diese Nachweise führen, indem er den DNS-Server veranlasst, die entsprechenden Statistiken zu führen. Das Problem nur ist: Wenn der LAN-Analyst seine Diagnose betreibt, ist der DNS-Admin in Urlaub, krank, schwanger oder gerade mit dem Auto auf dem Weg zum Dienst liegen geblieben. WINS: Was WINS-Server anbetrifft, lautet der Befund: Leider sind ihm keine genauen Statistiken abzuringen. Der Microsoft WINS-Server gibt zwar Zahlenwerte als Statistik aus bzgl. der erfolgreichen und erfolglosen Namens- und Adress-Auflösungen; aber es gibt keine Aufschlüsselung im Einzelnen, welche Namen in welcher Häufigkeit angefragt wurden.

Die einzige Chance, zu verlässlichen Aussagen zu kommen, ist, den LAN-Analyzer zu veranlassen, diese Statistiken und Tabellen automatisch zu erzeugen und auszugeben. Auf diese Weise ist der Bearbeiter unabhängig von der Hilfe verschiedener Name Server-Admins. Genau das aber leisten die gängigen LAN-Analyzer nicht. Damit ist der Weg zu wichtigen Erkenntnissen versperrt. Der im Beispiel angegebene Name übrigens (JSPNRMPTGSBSSDIR) scheint über Windows RAS-Maschinen in die Netzwerke eingestreut worden zu sein. Jedenfalls gibt es einen Eintrag in der Microsoft Knowledgebase, der diesen Zusammenhang herstellt. Einen Hinweis auf die letzte Ursache oder den möglichen Fehler gibt es dabei leider nicht; was aber auch egal ist, weil dieser Name (der in vielen Windows-Netzwerken herumspukt) einfach nur ein Beispiel ist für Abweichungen und Erscheinungen dieser Art ganz allgemein. Der Name JSPNRMPTGSBSSDIR ist 16 Zeichen lang und hat somit die maximale Länge der NetBIOS-Namenskonvention. Um einen formal »echten« Microsoft NetBIOS-Namen jedoch kann es sich nicht handeln, da Microsoft für den beschreibenden Namensteil nur die ersten 15 Zeichen verwendet; das 16. Zeichen wird für die Kodierung des NetBIOS-Ressourcen-Typs verwendet (z.B. Kennzeichnung als Domain-Server, Master-Browser etc.).

60

>>> NEW TECH

Das Scheitern auf OSI Layer 7 = Application

2.13 Das Scheitern auf OSI Layer 7 = Application Die heute verfügbare Netzwerk-Technik ist – von Ausnahmen abgesehen – im Campus-LAN so zuverlässig, dass auf den OSI-Schichten 1-4 wenig Fehler wirklich von Belang sind. (Um ein Missverständnis auszuschließen: TCP-Ereignisse gibt's natürlich immer reichlich, aber sie gehen nicht wirklich auf TCPeigene Fehler zurück. TCP-Ereignisse sind allgemein die Folge von Fehlern andernorts.) Somit wird es immer wichtiger, die Analyse auf der Applikations-Schicht in den Mittelpunkt der Campus-LAN-Diagnose zu stellen. Die klassische TCP/IP-Analyse ist eher unter WAN-Bedingungen bedeutsam (von durchaus vorhandenen Sonderfällen auch im LAN mal abgesehen). Ein paar Beispiele sollen die höchst eingegrenzten Fähigkeiten der gängigen LAN-Analyzer umschreiben:

2.13.1 Datei-Operationen: korrekt, aber wahnsinnig Oft ist die Grenze zwischen Genie und Wahnsinn schwer zu erkennen, wie schon der Volksmund treffend zu berichten weiß. In der Welt der beiden maßgeblichen Client-Server-Protokolle erhält dieses Sprichwort seine ganz eigene Bedeutung: ■ ■

SMB (Server Message Block): Windows, OS/2, Samba NCP (NetWare Core Protocol): Novell NetWare

Fast alle Vorgänge, die zwischen Client und Server von Belang sind, werden bei Windows und NetWare mit diesen beiden Protokollen abgehandelt: Login, Logout, File Services, Print Services. Nur die Namensdienste (Name Services) sind eher selbstständig (WINS, DNS), ebenso die Endgeräte-Konfiguration über BOOTP-DHCP. Wie nun können Dateizugriffe korrekt, aber wahnsinnig sein? Die folgenden Beispiele sollen einen Einblick geben. Was hier in diesem Kapitel von Belang ist: Die am Markt eingeführten LANAnalyzer geben kaum eine Chance, die folgend beschriebenen Vorgänge in ihrer systematischen Fehler-Charakteristik zu erkennen.

2.13.2 Diagnose durch Quantifizierung braucht Qualifizierung Die folgenden Beispiele werden ein Grunddilemma herkömmlicher LAN-Analyse aufzeigen: Wenn der Betrachter nicht gerade die eingefangenen LAN-Pakete manuell durchsieht, beschränkt sich der Analyzer weitgehend auf die Ausgabe von Sta-

>>> NEW TECH

61

Kapitel 2 • LAN-Analyzer in der Kritik

tistiken. Statistiken sind unverzichtbar, bei guter Anlage sogar sehr hilfreich, aber sie leiden an einem entscheidenden Mangel: ■ ■

■

Statistiken sagen nichts oder nur wenig über Ursache-Wirkungs-Verhältnisse bzw. Wechselwirkungen aus. Statistiken können chronologische Ereignisabläufe nicht sichtbar machen, denn die Zeitachse geht ebenso (ganz oder teilweise) verloren wie inhaltliche Aspekte. Statistiken können wichtige Bewertungen nicht vornehmen, die für die Klassifikation als »gut« oder »fehlerhaft« unabdingbar sind.

Daraus lässt sich ein einfacher, aber wichtiger Lehrsatz zur LAN-Analyse ableiten:

HINWEIS Erster Merksatz der LAN-Analyse: Jede quantifizierende Methode (= Statistik) muss durch ergänzende qualifizierende Methoden (= inhaltliche Betrachtung und Wertung) wenigstens in Stichproben ihre Ergebnisse rechtfertigen bzw. einordnen.

In der empirischen Sozialforschung ist das längst allgemeines Verfahren. So käme beispielsweise in der Wahlforschung niemand auf die Idee, sich mit den Prozentzahlen zufrieden zu geben, in denen sich die Wähler für die Parteien ausgesprochen haben. Denn zu den wichtigen Fragen gehört die Betrachtung der Wählerwanderung. Das Ergebnis dieser Betrachtung enthält zwar auch wieder Zahlen und Statistiken, aber es kommt nur durch inhaltliche Betrachtungen zu Stande. Im Umfeld der LAN-Analyse bedeutet das: Zahlen wie etwa »Pakete pro Sekunde« oder »Megabytes pro PC« sind zwar Hinweise auf das, was geschieht, aber diese Zahlen können schon einfache Fragen wie die folgenden nicht beantworten: ■ ■

Ist der Datenverkehr, der von einer Station ausgeht, überhaupt nötig – oder nicht? Bewegt sich da jemand in einer Endlosschleife, oder handelt es sich um sinnvolle Vorgänge?

Herkömmliche LAN-Analyzer können solche Unterscheidungen nicht treffen. Entsprechend gemindert ist der Wert ihrer Statistiken (etwa: Top Talkers). Nun also die Beispiele, die zeigen sollen, welche Ereignisse zu katastrophalen Folgen führen können – und die über Statistiken schlecht greifbar sind:

62

>>> NEW TECH

Das Scheitern auf OSI Layer 7 = Application

2.13.3 Get File Size: 3.000-mal pro Sekunde Bei einem Kunden in Köln – mit ein paar tausend Mitarbeitern bzw. PCs in der Verwaltung – konnte folgende interessante Szenerie beobachtet werden: Ein Client-PC hatte die fixe Idee, ständig denselben Server nach der Größe der immer selben Datei zu befragen. Stets gab der Server prompt die Antwort, stets war die aktuelle Antwort identisch mit der jeweils vorherigen Antwort und niemals kam der Client-PC auf den Gedanken, mit dieser Datei überhaupt irgendetwas anzufangen: an ein Öffnen, Lesen, Löschen war aktuell jedenfalls gar nicht gedacht. Das Pikante war: Der Client-PC brachte es auf eine Abfrageleistung von 3.000 Get File Size-Requests pro Sekunde!! Das war und ist für den Verfasser dieser Zeilen persönliche Bestleistung. Schlimmer war es noch nicht beobachtet worden. Der Server hatte Glück: Dieses Verhalten trat nur sporadisch auf, es kamen nicht hunderte von Client-PCs gleichzeitig auf die Idee, solches zu tun. Der Wahnsinn, so könnte man sagen, verteilte sich über die Zeit. Hätten jedoch womöglich hunderte von Arbeitsrechnern dasselbe Verhalten zur selben Zeit an den Tag gelegt, so wäre ein erheblicher Einbruch in der Antwortzeit des Servers unausweichlich gewesen. Die Aussage des Kunden war, dass es solche Einbrüche in der Server-Performance tatsächlich immer wieder gegeben habe; am Tage der Messung leider war es nicht nachweisbar. Zu vermuten jedoch war in der Tat, dass es hier einen Zusammenhang gab. Jetzt zur Kritik an den Analyzern: Die jeweils einzelne Abfrage Get File Size samt der Server-Antwort darauf war – für sich genommen und isoliert betrachtet – völlig korrekt. Alle Pakete waren gesund: kein Prüfsummen-Fehler, keine Retransmissions, nichts. Aus der Sicht der verwendeten Analyzer jedoch fiel lediglich auf, dass der in Rede stehende Client-PC eine erhöhte Sendeleistung hatte – das aber wäre für sich nicht weiter auffällig, denn das kann bei völlig regulären Zugriffen auch so kommen. Also achtete niemand darauf. Nimmt man weiter an, dass der Analyzer zwei Stunden an der Leitung hing und dass vielleicht fünfzig oder hundert Aufzeichnungs-Dateien (Trace-Files, Capture-Files) auf der Festplatte gespeichert waren, so kommt unweigerlich das nächste Dilemma auf: Wie soll ein solches Fehlverhalten eines Rechners zuverlässig entdeckt werden, wenn die in Stichproben ablaufende manuelle Betrachtung der Trace-Dateien auf pures Glück angewiesen ist, um die jeweilige Fundstelle auch zu treffen?

>>> NEW TECH

63

Kapitel 2 • LAN-Analyzer in der Kritik

Und hier wird einer der gravierendsten Mängel der Analyzer deutlich: ■ ■

Sie sind nicht in der Lage, mehrere (am Ende: hunderte) von Trace-Dateien automatisch zu durchlaufen und zu bewerten. Sie sind nicht in der Lage, über solche Ereignisse lesbare Berichte auszugeben, die eine schnelle und weitgehend zuverlässige manuelle Durchsicht erlauben.

Über diese Mängel wird noch zu späterem Zeitpunkt sehr gründlich zu sprechen sein.

2.13.4 Read File: Endlosschleife mit 100% Netzlast Bei einem anderen Kunden in Heidelberg wurde festgestellt, dass eine bestimmte LAN-Verbindung mit nahezu 100% Netzlast (auf Fast Ethernet) gefüllt war. Das Geschehen war genauso bizarr wie eindeutig: Ein einzelner Client-PC versuchte seit Tagen, eine einzelne Datei vom Server zu lesen. Dabei ging der Rechner wie folgt vor: ■ ■ ■

■

Er las sich von vorne nach hinten durch die Datei. Kurz vor dem Datei-Ende angelangt, sprang der Client an eine frühere Datei-Position zurück. Von dort aus ging es dann wieder weiter bis zu einer weit hinten liegenden Datei-Position und von dieser wurde dann wieder zurückgesprungen nach vorne. Das Datei-Ende wurde nie erreicht, die Datei wurde nie geschlossen.

Dieses Verhalten ist zwar exotisch, kommt aber öfter vor, als man denken möchte. Noch wenige Wochen vor Abfassen dieses Kapitels erlebte der Verfasser ein sehr ähnliches Szenario bei einem Kunden in Bergisch-Gladbach (bei Köln). In beiden Fällen (und allen anderen Fällen dieser Art, die es ja auch gegeben hat) konnte der Name der betroffenen Datei jeweils nicht ermittelt werden, da der Datei-Name nur ein einziges Mal vom Client an den Server gemeldet wird, nämlich bei Einleitung des Schreib/Lese-Zugriffs (der Server antwortet dann mit der Herausgabe eines so genannten File Handles, welches eine Art von Zugriffs- und Authorisierungs-Schlüssel darstellt). Dies führt zu der Frage: Wie ließe sich denn auf Umwegen der Datei-Name ermitteln? Nun, das mögliche Verfahren wäre folgendes: ■ ■

64

Die erkannten Missetäter (die beteiligten Rechner) werden ausgeschaltet. Der LAN-Analyzer wird so geschaltet, dass er sämtlichen Datenverkehr dieses Rechners mitlesen und aufzeichnen kann. Klassisch wäre, den Client-PC sowie den LAN-Analyzer auf denselben Fast Ethernet-Hub zu legen und diesen dann erst mit dem Switch zu verbinden.

>>> NEW TECH

Das Scheitern auf OSI Layer 7 = Application

■

■ ■

Sodann wird der Client-PC gestartet. Die Messung läuft so lange mit, bis über die Statistik, das heißt bis über erhöhtes Sendevolumen des Client-PCs der Hinweis kommt, dass wieder eine Endlosschleife begonnen wurde. Sodann wird durch manuelle Stichproben in den Messdaten verifiziert, ob bzw. dass der Client-PC tatsächlich wieder in die Endlosschleife geraten ist. Ist das so, wird die Aufzeichnung beendet. In der Folge werden die Messdaten ausgewertet, und es wird ... – ... erkannt, wann bzw. an welcher Stelle die Endlosschleife auftrat, – ... erkannt, welcher Datei-Name vom Client zu Beginn übermittelt wurde, – ... erkannt, welche Umstände überhaupt zum Aufruf der Datei geführt haben.

Dieses Verfahren ist zuverlässig und sein Erfolg hängt nur von zwei Bedingungen ab: 1. Der Fehler muss erneut auftreten. 2. Die Analyse-Software muss in der Lage sein, ggf. hunderte von Aufzeichnungs-Dateien automatisch zu verarbeiten und zielgerichtete Reports auszugeben. In diesem Falle bedeutet das: Das fehlerhafte Zugriffsverhalten muss erkennbar sein und es muss ohne große Mühe der Datei-Name (der ja nur ein einziges Mal im Klartext über die Leitung geht) erkennbar sein. Von der ersten Bedingung mal abgesehen, die mehr oder weniger auf Zufall oder langer Geduld beruht, kann über die zweite Bedingung klar gesagt werden: Sämtliche am Markt eingeführten LAN-Analyzer verfügen nicht über die notwendigen Fähigkeiten, um die Lösung herbeizuführen. Die auf der CD-ROM dem Buch beiliegende Analyse-Software TraceMagic dagegen kann genau das und ist daher in der Lage, auch sporadische Fehler zu erkennen bzw. nachzuweisen, die eine Auswertung der Messdaten aus langen Zeitabschnitten verlangen. Bedingungen und Nutzungsformen einer solchen Auswertungstechnik werden weiter unten noch gründlich besprochen.

2.13.5 Open File: Verstümmelung von Dateinamen Es wurde bei einigen der oben aufgeführten Beispiele bereits angeführt, dass Microsoft dem durchaus richtigen Ansatz folgt, fehlertolerant auf Abweichungen von der Norm zu reagieren. Hauptsächlich ist das Beschreiten von Ersatzwegen bekannt im Bereich der Namensdienste (WINS-Anfragen nach fehlgeschlagenen DNS-Anfragen und umgekehrt).

>>> NEW TECH

65

Kapitel 2 • LAN-Analyzer in der Kritik

Im Bereich der Datei-Dienste (File Services) kommt es zu ähnlichen Erscheinungen; nur sind diese Vorgänge eher unerwünscht, völlig unkoordiniert und teilweise von erheblicher Fehlerhaftigkeit. Zu den verrücktesten Vorgängen gehört, wenn Dateinamen vom Client-PC verstümmelt werden. In der Windows-Netzwerk-Umgebung sind solche Verstümmelungen nicht selten. Der Verfasser würde veranschlagen, dass in etwa jedem zweiten WindowsNetzwerk solche Verstümmelungen nachweisbar sind; mal mehr, mal weniger. In vielen Fällen lässt sich nachweisen, dass ein Zusammenhang besteht zu Kommandos, die in Script-Dateien auftreten. Da die Verstümmelungen oft in Form des Austauschs von Platzhaltern durch andere Zeichen auftreten, ergibt sich die Vermutung eines Zusammenhangs zu Script-Befehlen von selbst. Der Zusammenhang ist aber nicht zwingend, da auch Programmierer im Applikations-Code durchaus mit Platzhaltern arbeiten können. Ein paar Beispiele: ■

■

■

■

66

Platzhalter in Dateinamen wie etwa ??? oder * werden ersetzt durch unzulässige Syntax-Zeichen, nämlich < oder >. Das Ergebnis könnte die Suche nach einer vermeintlichen Datei namens WIN>>>>.DLL sein. Es wird nach Dateien gesucht, die es nicht gibt, und das noch in verfälschter Form. Dies ist gut nachweisbar bei der Suche nach der vermeintlichen Datei echo.*. Zunächst einmal ist es völlig unsinnig seitens eines Client-PCs, überhaupt eine ausführbare Programm-Datei zum Script-Befehl ECHO zu suchen: Eine etwaige Datei echo.exe oder echo.com oder gar echo.dll gibt es eben nicht. Nun, dabei aber bleibt es nicht: Statt artig nach (es folgen absichtlich Großbuchstaben) ECHO.* zu suchen, wird nach ECHO" gesucht – will sagen: Statt eines Punktes zwischen dem Namensteil ECHO sowie dem Platzhalter * erscheint ein Gänsefüßchen ". Kein Wunder, dass jeder Netzwerk-Server behauptet, eine solche Datei noch nie gesehen zu haben und sie daher auch nicht liefern zu können. In besonders krassen Fällen werden zwar formal korrekte, aber letztlich doch völlig aberwitzige Dateinamen gebildet, indem allerlei Namenskombinationen probiert werden. Da sucht beispielsweise ein Client-PC nach WINSPOOL.DRV. Schade, nicht gefunden. Na gut, denkt sich der ClientPC, viel hilft viel, versuchen wir's doch mal so: WINSPOOL.DRV.DLL und WINSPOOL.DRV.COM und so weiter und so weiter. Auch hier ist es kein Wunder, dass der Server bei bestem Bemühen wirklich nicht helfen kann. Zu den schönsten Verballhornungen gehört es, wenn völlige Phantasienamen gebildet werden. So konnte bei verschiedenen Kunden beobachtet werden, wie SAP-Clients die Suche nach SAPLOGIN.EXE ausdehnten auf SAPLOGIN AUTOLOGIN.EXE, dann auf SAPLOGIN AUTOLOGIN 001.EXE, dann auf SAPLOGIN AUTOLOGIN 001 .EXE, und am Ende auf SAPLOGIN AUTOLOGIN 001 .EXE (sinngemäß; genaue Darlegung dieses wichtigen Beispiels erfolgt in einem gesonderten Kapitel weiter unten).

>>> NEW TECH

Das Scheitern auf OSI Layer 7 = Application

■

Auch nicht schlecht war eine Angewohnheit von Windows-Clients (vermutlich zurückgehend auf Windows NT 4 mit Service Pack 5), auf dem Server die Datei NTUSER.LOG.DAT abzulegen in immer länger werdenden Namensketten: NTUSER.LOG.DAT.NTUSER.LOG.DAT.NTUSER. LOG. DAT.NTUSER.LOG.DAT ... und so weiter und so weiter, bis 255 Zeichen erreicht waren und damit auch das Ende der Fahnenstange. Die Festplatte des Windows-PDC (eines Kunden in München) war reichlich gefüllt mit allen Zwischenstufen dieser Kettennamen und das von vielen, vielen Client-PCs.

Alle diese völlig irren Versuche, einer Datei noch irgendwie habhaft zu werden, indem der Datei-Name mutiert wird, werden von gängigen Analyzern nur dann sichtbar gemacht, wenn der Betrachter das Datenpaket, welches die ClientAnforderung enthält, einzeln betrachtet und sich dann seine eigenen Gedanken macht. Nur: Wie soll das gehen, wenn der LAN-Analyzer ein paar Stunden an der Gigabit-Leitung hing und ein paar tausend Trace-Dateien auf die Festplatte schrieb? Selbst dann, wenn die Messung in einer kleinen Client-Workgroup stattfand, kommen morgens in der Zeit des Bootens und Einloggens schnell 100, 200 Megabytes an Messdaten zusammen – zu viel, um manuell zuverlässig auswertbar zu sein. Nur ein automatisches Auswertungsverfahren, das alle Trace-Dateien, die der Analyzer auf die Festplatte schrieb, vollständig durchsucht und zielgerichtete Reports erzeugt, kann solche Fehlerabläufe dokumentieren und sichtbar machen. Hier erklärt sich einmal mehr der Ansatz von TraceMagic, nicht in Stichproben zu suchen, sondern auch Gigabytes von Messdaten voll automatisch zu durchlaufen, um jeglichen Wahnsinn dieser Art herausziehen zu können.

2.13.6 Open File: Dateien werden gesucht, wo sie nicht hin gehören Gut, wird man sagen können, das vorige Beispiel sei vielleicht extrem und defekte Dateinamen kann man ja noch von Hand erkennen (vorausgesetzt, man findet in Stichproben die richtigen Fundstellen). Aber noch schwieriger wird es, wenn die angeforderten Dateinamen völlig korrekt aufgebaut sind und keinen unmittelbaren Anlass zu Verdacht geben – nämlich dann, wenn Dateien schlicht am völlig falschen Ort gesucht werden. ■

■

So wurde mehrfach beobachtet, dass SAP-Clients, die zugleich auch auf Oracle-Datenbanken zugriffen, von der fixen Idee besessen waren, die SAPDateien in den verschiedenen Oracle-Verzeichnissen zu suchen. Kein Wunder, dass Anwender dann sagen: »SAP/R3 ist aber mal wieder langsam.« Das liegt dann nicht unbedingt an SAP! Ein besser verifizierbares Beispiel ist der zum Teil völlig unsortierte Umgang mit der Datei DESKTOP.INI – denn diese Datei wird immer wieder gerne in Verzeichnissen gesucht, wo sie wirklich nicht hingehört. Im besten Fall ist

>>> NEW TECH

67

Kapitel 2 • LAN-Analyzer in der Kritik

■

der gewollte Ablageplatz für DESKTOP.INI das User-Home-Verzeichnis. Das hält aber Windows-Clients nicht davon ab, die Datei auch in Applikations-Verzeichnissen zu suchen und auch auf Servern, auf denen die Datei sowieso nicht abgelegt werden dürfte. Ebenso gern gesehen ist die Suche nach NTUSER.DAT in Verzeichnissen, in denen diese Datei eher nicht vermutet würde, etwa im Verzeichnis der Microsoft Office Suite oder irgendwo bei Drucker-Treibern. Manchmal freut man sich geradezu schon, dass überhaupt etwas mal gefunden wird. ...

Diese Beispiele sind insofern willkürlich, da es hier zunächst einmal um den Schau-Effekt ging, um zu demonstrieren, welche üblen Fehler bei der DateiHolung auftreten können, ohne dass diese Fehler von herkömmlichen LANAnalyzern ausgewiesen würden. Dass diese Fehler zum Teil massiv die Arbeitsleistung der angeschlossenen Client-PCs beeinträchtigen können, wird in einem gesonderten Abschnitt in der Folge dieses Buches beschrieben werden. Es handelt sich um ein sehr ernst zu nehmendes Thema, zumal hier Fragen der Geräte-Konfiguration eine erhebliche Rolle spielen können. Hier war unmittelbar darauf hinzuweisen, dass herkömmliche Analyzer solche Vorgänge in ihrer Fehlerhaftigkeit nicht erkennen, da sie äußerlich formal korrekt ablaufen. Zwar zeigen sie an, dass die Antwort des Servers in einem solchen Falle eine Ablehnung enthält; aber sie machen eben nicht sichtbar, ■ ■ ■ ■ ■

ob es sich um vereinzelte Ereignisse handelt, ob es sich um eine Massenerscheinung handelt, ob die Fehler eine eigene bzw. innere Systematik erkennen lassen, ob die Fehler mit Geräte-Einstellungen zu tun haben könnten, ob die Fehler mit Script-Befehlen zu tun haben könnten (Login-Script, .CMD, .BAT).

Der schlüssige Nachweis, dass systematische Fehler vorliegen und dass sie zuverlässig und massenhaft auftreten, ist über Stichproben nicht zu erbringen. Nur die vollständige und automatische Auswertung von Messdaten eines längeren Zeitraums (etwa eines halben oder ganzen Tages) kann hier die nötige Diagnose stellen. Dieser Nachweis ist mit den Online-Expertensystemen der Analyzer nicht nicht zu erbringen. Nur eine Offline-Auswertung, die auch komplizierteren Zusammenhängen nachspüren kann, kann das leisten. Damit sind wir wieder bei TraceMagic angelangt, denn nach dem Wissen des Verfassers ist diese Software als einzige in der Lage, zum Beispiel von sich aus Zusammenhänge zwischen diversen Scripts, die der Client vom Server lädt (und abarbeitet) und später scheiternden Zugriffen auf verschiedene Server-Ressourcen herzustellen.

68

>>> NEW TECH

Das Scheitern auf OSI Layer 7 = Application

Im weiteren Verlauf des Buches werden einige hoch interessante Beispiele aus diesem Bereich vorgeführt und besprochen. Wichtig in diesem Kapitel, in dem es um eine allgemeine Kritik der bekannten LAN-Analyzer geht, ist die Feststellung, dass eine wichtige Klasse von Fehlern kaum oder gar nicht nachweisbar war; erst mit TraceMagic werden die Tore zur Erkenntnis aufgerissen.

2.13.7 Applikations-Fehler im Zusammenhang mit Fehlern der Schichten 1–4 Herkömmliche Analyzer bieten fast überhaupt keine Chance, versteckte Abhängigkeiten zwischen Fehlern zu finden, die auf der Applikations-Ebene ablaufen, und Ereignissen (gar nicht mal unbedingt Fehlern), die auf den Netzwerk-Schichten 1-4 ablaufen. Ein sehr prägnantes Beispiel konnte der Verfasser im Jahr 2002 bei einem Kunden beobachten, der über Probleme klagte, die Anwender bei Zugriffen auf die Oracle-Datenbank hätten. Es stellte sich am Ende der Untersuchung heraus, dass bestimmte Zugriffe der Oracle-Clients scheiterten, wenn die IP-Pakete auf OSI Layer 3 im Zuge der Übertragung von A nach B in ihrer Reihenfolge verdreht wurden. Eine solche Verdrehung der Paketreihenfolge tritt in aller Regel nur als Wirkung folgender Ursachen auf: ■

■

Es gibt zwischen Sender und Empfänger ein größeres Routing-Netzwerk (WAN) und die Pakete durchlaufen verschiedene Teilstrecken. Ein solches Verhalten ist oft die Folge von Überlastungen einzelner Leitungen, von Ausfall einzelner Leitungen oder vom Absturz einzelner Router. Es findet eine Verletzung des FIFO-Prinzips innerhalb eines Switches oder Routers statt, will sagen: Die einzelnen Pakete werden nicht in der Reihenfolge ihres Eintreffens weitergeleitet, sondern in willkürlicher Zufallsfolge. Die Abkürzung »FIFO« steht für »First In/First Out« und kennzeichnet somit die gewünschte Arbeitsweise.

Nun, im vorliegenden Falle der Oracle-Probleme stellte sich eben heraus: Wenn IP-Pakete in ihrer Reihenfolge verdreht waren, kam es bei bestimmten ClientZugriffen (aber nicht bei allen!) nach einer gewissen Verzögerungszeit zum Abbruch der Sitzung seitens des Oracle-Servers. Das muss nicht bedeuten, dass die Oracle-Datenbank fehlerhaft wäre. Viel eher wahrscheinlich war bzw. ist ein Fehlverhalten des TCP/IP-Treibers, der verdreht einlaufende Pakete eigentlich in ihre korrekte Reihenfolge zurückzusetzen hätte. Leider kann der Verfasser die Lösung nicht mitteilen, da er nach der Diagnose keine Zeit mehr hatte, den weiteren Fortgang der Ereignisse beim Kunden zu beobachten. Da aber der Befund bei zwei verschiedenen Kunden erhoben werden konnte, ist die Diagnose für sich als fest anzusehen.

>>> NEW TECH

69

Kapitel 2 • LAN-Analyzer in der Kritik

Wie auch immer: Herkömmliche Analyzer sind nicht oder kaum in der Lage, den Zugang zu solchen Zusammenhängen zu eröffnen. Zugegeben, auch TraceMagic ist nicht in der Lage, ein Popup-Fenster zu öffnen mit der Mitteilung, dass IP-Ereignisse die Oracle-Zugriffe abstürzen lässt. Aber die sehr eigene Form der Berichtsausgabe seitens TraceMagic erlaubt, bei manueller Durchsicht der Reports sehr schnell und sehr unkompliziert den Zusammenhang zu erkennen (es fällt schwer, den Zusammenhang nicht zu sehen). Somit spielt auch die Form der Berichtsausgabe eine Rolle. Sie muss so beschaffen sein, dass auch Fehler gut zugänglich sind, die vom Analyse-Programm selber nicht erkannt werden. Herkömmliche Analyzer scheitern leider schon daran, überhaupt mal lesbare Berichte auszugeben. Ein Hersteller, der allen Ernstes seine Anwender dazu zwingt, Analyzer-Screenshots in eine Word-Datei zu legen, um sie sodann eigenhändig und mühselig zu kommentieren, hat nicht verstanden, welche Methoden bei großen Datenmengen zwingend erforderlich sind, und er hat kein Verständnis für die immense Zeitnot, unter der Netzwerk-Admins leiden. Aus diesem Blickwinkel kann der Verfasser nicht verhehlen, sämtliche »Marktführer« der LAN-Analyse schon seit Jahren nicht mehr ernst nehmen zu können. Der Zuspruch, den er übrigens erfahren hat für sein erstes Buch, den Networker’s Guide. LAN Analysis und Windows Troubleshooting (im selben Verlag erschienen), ist Beweis genug dafür, dass nicht wenige von Ihnen, werte Leser, eigenständig zu ähnlichen Auffassungen gelangt waren.

2.13.8 Anwenderaktionen werden falsch umgesetzt (Beispiel: SAP/R3) Das folgende Beispiel, erlebt bei einem Kunden in München, ist bezeichnend für die zum Teil völlig bizarren Fehler, die manches Mal die Anwender zum Fluchen bringen. Das Beispiel ist zwar, wie unten noch dargestellt wird, nicht im engeren Sinn geeignet, die Fähigkeiten der Analyzer in Zweifel zu ziehen; es zeigt aber sehr wohl, dass wichtige zusätzliche Funktionen fehlen, um sehr vertrackten Fehlern auf die Spur zu kommen. Folgendes war geschehen: Mehrfach erlebten Anwender, dass ein Mausklick auf eine Schaltfläche der SAP/R3-Bedieneroberfläche erst zu langem Warten, dann zu einer Fehlermeldung, wenn nicht gar zum Absturz des SAP-Clients führte. Der Verdacht wendete sich zunächst gegen den SAP-Server. Eine Messung dort jedoch ergab keine weiteren Hinweise auf den Ablauf oder auf die Ursache.

70

>>> NEW TECH

Das Scheitern auf OSI Layer 7 = Application

Also wurde die nächste Messung neben einem der Client-PCs durchgeführt, dessen Anwender besonders häufig diese Fehler erlitten hatte (und dessen Rechner daher besonders Aussicht darauf gab, bei einer Messung den Fehler zu erzeugen oder zu erleiden). Der Anwender meinte, es gäbe eine Aktion, die mit guter Aussicht auf Erfolg im Fehler enden würde. Er öffnete das entsprechende Menü innerhalb der SAP-Oberfläche und führte schließlich den Mausklick aus, der nach Ansicht des Anwenders entscheidend war. Und tatsächlich: Es kam eine längere Wartezeit; dann erschien eine Fehlermeldung, die sinngemäß mitteilte: »Keine Antwort vom Server.« Auf Grund dieser Fehlermeldung war auch zunächst der Verdacht geäußert worden, der SAP-Server würde nicht korrekt arbeiten. Dass den SAP-Server keine Schuld traf, war aber bereits ausgeräumt worden durch besagte erste Messung direkt am SAP-Server. Also kam es nun auf die Ergebnisse der Messung direkt neben dem SAP-Client an; und siehe da, es konnte schnell geklärt werden, was da geschah: Kaum erfolgte der Mausklick in der SAP-Oberfläche, begann der Windows-PC energisch, Installations-Dateien auf einem Novell-NetWare-Server zu suchen, der weder etwas mit SAP, noch aktuell mit diesem Windows-Client, noch mit den gesuchten Installations-Dateien zu tun hatte. Der völlig unschuldige NetWare-Server hatte die geforderten Dateien nicht vorrätig (jedenfalls nicht in den angegebenen Verzeichnissen) und irgend eine SAPAnfrage war überhaupt nicht ersichtlich. Es war auch nicht erkennbar, was eigentlich das SAP-Client-Modul und/oder den Windows-PC dazu brachte, nach dem Mausklick diese völlig sinnlose Aktion auszuführen. In jedem Falle hieß es mal wieder: »Das Netzwerk ist langsam.« So weit, so gut, so unterhaltsam. Das Beispiel soll Folgendes verdeutlichen: Fehler dieser Art können von Analyse-Programmen kaum automatisch zugeordnet und entschlüsselt werden. Denn der Mausklick des Anwenders ist auf der Leitung nicht zu sehen und dass die Suche nach den Installations-Dateien ins Leere läuft, ist zwar unschön, aber anhand der Messdaten unmöglich einem SAP-Ereignis zuzuordnen. Es gibt also Fehler, die im Grunde überhaupt nicht durch automatische Auswertungsmechanismen »gepackt« werden können. Bis hierhin gilt, dass die LAN-Analyzer entlastet sind, wenn sie bei solchen Fehlerabläufen nur die manuelle Durchsicht der Pakete als Lösungsweg lassen. Gleichwohl aber stellen sich hier Fragen: Wie müsste ein Analyzer beschaffen sein, damit dem Anwender eine möglichst einfache, aber eben auch möglichst effiziente manuelle Durchsicht ermöglicht wird?

>>> NEW TECH

71

Kapitel 2 • LAN-Analyzer in der Kritik

Im aktuellen Fall bestand ja noch das Glück, dass der Analyst gleich am Nachbartisch saß und verfolgen konnte, was der Anwender tat und – vor allem – wann er es tat. Bei Messdaten aber, die beispielsweise über CD-ROM zugesendet werden und bei denen Begleitinformationen wie Uhrzeit etc. fehlen, ist es ungleich schwerer, sich einem solch unbestimmten Fehler zu nähern. Hier macht sich, um einmal mehr auf TraceMagic zu sprechen zu kommen, deutlich bezahlt, wenn der Anwender nicht allein auf die Durchsicht der LANPakete im Analyzer angewiesen ist, sondern wenn er zusätzliche Möglichkeiten an die Hand gelegt bekommt. Im Falle von TraceMagic ist dies eine chronologische Ereignisausgabe in Form einer Text-Datei, die ein schnelles, übersichtliches Durcharbeiten erlaubt und nebenbei ein simples Kommentieren für jeden Dritten, der diese Datei zugesendet bekommt.

2.13.9 Voice over IP läuft nicht richtig: versteckte Fehler im WAN Das folgende Beispiel zeigt, dass in schwierigen Fällen nur eine übergreifende Zusammenschau aller Protokolle und Ereignisse zum Ergebnis führen kann. Ein Kunde klagt darüber, dass sein Voice over IP Projekt unter massiven Fehlern leidet. Der WAN-Provider ist eingebunden, kann aber mit seinen Messungen nichts finden. (Aussage: »Unsere Leitungen sind in Ordnung.«) Der VoIP-Ausstatter hat an zwei Endpunkten (Hauptstelle, Niederlassung) jeweils einen Laptop stehen mit einem VoIP-Simulator. So kann festgestellt werden, dass VoIP-Pakete verloren gehen. Immerhin: Die Aussage der Anwender, dass die Telefonate schlechte Qualität haben und bisweilen abreißen, hätte man sonst womöglich gar nicht glauben können. Alle zusammen aber haben keine Idee. Woran kann es liegen? Eine automatische Analyse des WAN-Traffics aus einem Zeitraum von 3-4 Stunden (synchron aufgenommen in Hauptstelle und Niederlassung) zeigt: Es gibt versteckte Fehler in der WAN-Wolke – Fehler, die es nach den Aussagen des WAN-Providers nie hätte geben dürfen. Die Struktur des übertragenden IPund Frame-Relay-Netzes ist anders, als bis dahin behauptet. Insbesondere die VoIP-Paketverluste werden somit auf einmal verständlich. Eine Analyse, die lediglich die VoIP-Abläufe beachtet hätte, wäre niemals zu einem solchen Ergebnis gekommen. Da aber die Betrachtung langer Zeiträume, die automatische Auswertung samt klarer Aussagen über Zusammenhänge der Layer 3 (Routing), 4 (Transport) und 7 (Application) sowie die entsprechende Erzeugung von Reports von den klassischen Analyzern nicht geboten wird, war in diesem Fall klar: Ohne ein Werkzeug wie TraceMagic wäre es nicht möglich gewesen, die Nuss zu knacken.

72

>>> NEW TECH

Das Scheitern beim Filtern

Hierbei spielt eine große Rolle, dass WAN-Provider gerne die ICMP-Meldungen ihrer eigenen Router dem Kunden gegenüber unterdrücken, heißt: Die ICMP-Meldungen der WAN-Router werden nicht ins Campus-LAN des Kunden ausgegeben. Trotzdem sollte ein LAN-Analyzer in der Lage sein, aus den KommunikationsMerkmalen anderer Protokolle die nötigen Hinweise zu gewinnen, die zum Erkennen dem im WAN versteckt ablaufenden Fehler nötig sind (sofern vorhanden). Die gängigen LAN-Analyzer der selbst ernannten Weltmarktführer jedoch können dies nicht (oder nur höchst unvollkommen) – ausnahmslos. In den späteren Kapiteln wird das hier kurz angedeutete Beispiel besprochen (Fallstudie Voice over IP im Layer-7-Teil des Buches).

2.14 Das Scheitern beim Filtern Alle LAN-Analyzer bieten Funktionen zum Filtern. Doch schon auf den zweiten Blick stellt sich vieles nicht mehr so dar wie noch beim ersten Blick und wer als Profi auf fortgeschrittene Filterfähigkeiten angewiesen ist, wendet sich alsbald völlig desillusioniert ab. Die folgenden Beispiele gehen an die Schmerzpunkte der bekannten Analyzer. Mancher LAN-Analyst, der über Jahre glaubte, mit seinem Analyzer glücklich zu sein, wird nun möglicherweise erkennen (müssen), dass er über Jahre mit Magerkost abgespeist wurde. Filter sind eine unverzichtbare Technik, um aus großen Datenmengen gewünschte bzw. gesuchte Inhalte herauszuziehen. Ist diese Fähigkeit begrenzt oder sogar fehlerhaft, sind angestrebte Ergebnisse nicht zu erzielen oder es kommt sogar dazu, dass am Ende einer Analyse eine falsche Diagnose gestellt wird.

2.14.1 Filter auf IP-Adressen Die meisten Filter, die von Bearbeitern gesetzt werden, zielen auf MAC- und IPAdressen. Abgesehen davon, dass es einige Analyzer fertig bringen, auch bei Filtern auf MAC-Adressen noch Fehler zu machen (insbesondere im Token-Ring-Umfeld), ist in jedem Falle bei IP-Adress-Filtern damit zu rechnen, dass nicht immer das gewünschte Ergebnis erzielt wird. Zu den gängigen Einschränkungen oder Fehlern gehören die folgenden Erscheinungen: ■

Fehler Nummer 1: Die gewünschte IP-Adresse wird nur in den Adressfeldern der beiden Protokolle IP und ARP gesucht.

>>> NEW TECH

73

Kapitel 2 • LAN-Analyzer in der Kritik

■

74

Folge: Viele wichtige Datenpakete werden gar nicht als »Treffer« erkannt, insbesondere keine Server-Rückgaben bei BOOTP, DHCP, WINS, DNS. Weiterhin werden oft keine Pakete als »Treffer« erkannt, die im Zuge von Netzwerk-Management und Routing-Organisation IP-Adressen enthalten. Hierzu zählen beispielsweise LLC-Pakete von Cisco-Routern (kein IP-Protokoll, aber IP-Adressen). Aber auch exotisch anmutende Kombinationen sind möglich: In einer gemischten IP-IPX-Umgebung werden schon mal von den LAN-Admins die IPX-Netzwerk-Adressen (die sich wie eine IP-Adresse aus vier Oktetts zusammensetzen) identisch gesetzt mit den jeweiligen IP-Subnetz-Adressen. Warum sollte es nicht von Interesse sein, auch IPX-Pakete als Treffer mitzunehmen, deren Adressierung sich an das IP-Adress-Schema anlehnt? Die Programmierer der Analyzer machen viele Fehler. Einer davon ist: Sie schreiben Zeile für Zeile den Inhalt von RFCs ab (RFC: Request for Comment), aber von der Lebenswirklichkeit heutiger Netze haben sie wenig Kenntnis. Ihnen wird auch kaum Gelegenheit gegeben, sich diese Kenntnis anzueignen. Also wissen sie oft nicht, auf welche Fähigkeiten und Funktionen es im Ernstfall ankommt. Eine dieser Fähigkeiten ist, Zusammenhänge zwischen Vorgängen zu erkennen, die auf den ersten Blick eigentlich gar nichts miteinander zu tun haben. Denn Fehler sind oft nichts anderes als die unvermutete Verbindung von Elementen, die sehr wohl zusammen Sinn oder doch wenigstens Wirkung haben können. Und genau dann ist es wichtig, dass ein Filter völlig freigesetzt werden kann. Das starre Festhalten an den Adressfeldern der Protokolle IP und ARP jedenfalls greift zu kurz. Die Suche muss im Grunde wie eine Volltextsuche ablaufen: Gleich, wo eine IP-Adresse sich versteckt: Sie muss gefunden werden! Aber damit ist es ja noch nicht getan. Fehler Nummer 2: IP-Adressen erscheinen auf der Leitung in verschiedenen Formaten. In jedem Falle im 4-Oktett-Binär-Format (also schlicht eine 32-Bit-Folge, die als IP-Adresse interpretiert wird), aber auch im Textformat (dezimal, durch Punkte getrennte Adress-Bytes, etwa 192.168.1.2) etwa im Zuge der Übertragung einer Datei wie der /etc/hosts oder der LMHOSTS, aber auch im inversiven Textformat, wie es bei Inversiv-DNS-Abfragen gegeben ist und bei der die IP-Adresse rückwärts notiert wird (zu einer gegebenen IPAdresse wird der Host-Name gesucht, nicht umgekehrt) sowie als Bestandteil einer URL innerhalb einer HTTP-Anforderung. Das sind schon mehrere, verschiedene Darstellungs-Konventionen. Wenn man jetzt noch bedenkt, dass die Textvarianten in verschiedenen Zeichensätzen möglich sind, nämlich in ANSI/ASCII, Unicode, CIFS und DNS, so erhöht sich die Zahl der denkbaren Varianten dramatisch, in denen eine IP-Adresse abgebildet bzw. dargestellt sein kann. >>> NEW TECH

Das Scheitern beim Filtern

■

Hier kapitulieren praktisch alle LAN-Analyzer auf weiter Strecke. Und dies führt uns unten zu einer weiteren Filterschwäche, nämlich dem Umgang mit Zeichensätzen (siehe unten). Fehler Nummer 3: Bei dem Produkt eines der unbestrittenen Marktführer wurde noch im Sommer 2002 festgestellt, dass die IP-Adressen immer an einer festen Position gesucht wurden, nämlich gerechnet wie folgt: [MAC HEADER ETHERNET = 14 OCTETS] + [IP HEADER OHNE ADRESS-TEIL = 12 OCTETS]. Wurde IP jedoch nicht über nacktes Ethernet gesendet, sondern über LLCSNAP, so griff der ganze Filter nicht mehr. Folge: Auf Token-Ring oder FDDI war der IP-Filter überhaupt nicht anwendbar! Da kommt man aus dem Kopfschütteln wirklich nicht mehr heraus.

Alles das sind keine kleinen Misslichkeiten, sondern gravierende Kardinalfehler, die den Herstellern nach nun zehn Jahren und mehr niemals mehr unterlaufen dürften. Es kann nicht ausbleiben, an dieser Stelle wieder auf TraceMagic zu verweisen. Sobald TraceMagic erkennt, dass nach einer IP-Adresse gesucht wird, so wird automatisch abgefragt, welche Varianten bei der Filtersuche berücksichtigt werden sollen (oder eben nicht). Wer immer den Vergleich anstellt zwischen der Filterausgabe seines Analyzers und der von TraceMagic, dürfte – von Einzelfällen abgesehen – erhebliche Abweichungen feststellen. Streng genommen müsste man derlei LAN-Analyzer, die teilweise seit 10 Jahren und mehr verkauft werden, an die Hersteller zurück geben mit der knappen Bemerkung, dass zugesicherte Eigenschaften nicht eingehalten würden. Das ist bisher nicht sonderlich üblich. Warum eigentlich nicht?

2.14.2 Filter auf Textfolgen und Namen (NetBIOS, WINS, DNS etc.) Bei dem Thema »Text« und »Namen« stehen wir bei den meisten Produkten schlicht vor einer mittleren Katastrophe. Zeichenfolgen, die einen lesbaren Text ergeben, werden für gewöhnlich in einem der folgenden vier Zeichensätze übertragen (von SNA mit EBCDIC bewusst abgesehen, da es keine Client-Server-Sprache ist):

>>> NEW TECH

75

Kapitel 2 • LAN-Analyzer in der Kritik

Zeichensatz/ Name

Einsatzgebiet

ASCII/ANSI

Der ASCII-Zeichensatz wurde mit MS-DOS bzw. mit dem IBMPC populär. Ursprünglich mit 7 bzw. 8 Bits je Zeichen kodiert, ging der ASCII-Code inzwischen weitgehend in den ANSICode über, der mit MS Windows verbreitet wurde.

Unicode

Die älteren Varianten ASCII/ANSI hatten den Nachteil, dass die mit 8 Bits kodierten Zeichensatztabellen keine Chance boten, Sprachen außerhalb des lateinischen Alphabets zuverlässig zu bedienen. Insbesondere die ostasiatischen Sprachen mit ihrem Bildzeichen-Alphabet machten es nötig, die Zeichensätze von einer 8-Bit-Darstellung zu einer 16-Bit-Darstellung zu erweitern. Es gibt eine internationale Unicode-Kommission, die eine Vereinheitlichung aller Weltsprachen im UnicodeSystem anstrebt. Würde über Datenpakete hinweg ein Filter auf eine beliebige ASCII/ANSI-Textfolge gesetzt, so würden von vielen (wenn nicht den meisten) Analyzern die jeweiligen Unicode-Entsprechungen nicht gefunden.

CIFS

Das »Common Internet File System« wurde von Microsoft eingeführt im Zuge der Weiterentwicklung des SMB-Protokolls. Die RFCs 1001,1002 beschreiben SMB bzw. CIFS ausführlich. Allerdings ist SMB nicht zwingend auf CIFS festgelegt, auch ANSI/ASCII und Unicode werden unterstützt. Bei CIFS handelt es sich um eine ziemlich verschrobene 16-Bit-Variante, die unter anderem den Zweck verfolgte, längere Folgen von Nullen im Binär-Code zu vermeiden. Dies war in den 80-er Jahren auch für DNS von Belang. Einige der analogen Übertragungstechniken hatten Schwierigkeiten, wenn längere Folgen von Nullen im Bit-Strom auftraten. Heute ist CIFS zwar über MS-Windows und SMB immer noch stark vertreten; die ursprüngliche Motivation dieses Zeichensatzes ist jedoch nicht mehr vorherrschend. Microsoft ist heute eher bestrebt, mit dem Unicode zu arbeiten. Die etwas schräge Kodierung von CIFS ist im Networker’s Guide des selben Autors ausführlich beschrieben (siehe CDROM). Würde über Datenpakete hinweg ein Filter auf eine beliebige ASCII/ANSI-Textfolge gesetzt, so würden von vielen (wenn nicht den meisten) Analyzern die jeweiligen CIFS-Entsprechungen nicht gefunden.

Tabelle 2.2: Vorherrschende Zeichensätze und ihre Verwendungsformen

76

>>> NEW TECH

Das Scheitern beim Filtern

Zeichensatz/ Name

Einsatzgebiet

DNS

Wer immer in seinem Webbrowser www.microsoft.com eingibt, kommt gemeinhin gar nicht auf die Idee, dass diese simple Eingabe nicht eine einfache Textfolge darstellen könnte. Bei DNS werden jedoch auf der Leitung keine Punkte zwischen den einzelnen Namensbestandteilen übertragen, sondern Ziffern, die als Längenangabe dienen und die Länge des nächsten, folgenden Namensbestandteils angeben. So würde der Punkt vor ».com« ersetzt durch den Binär-Ausdruck 0x03, da ja das folgende »com« drei Zeichen lang ist. Würde über Datenpakete hinweg ein Filter auf diese Textzeile www.microsoft.com gesetzt, würden viele (wenn nicht die meisten) Analyzer entsprechende Treffer in DNS-Paketen nicht erkennen.

NetBIOS

Das NetBIOS-Protokoll arbeitet mal mit ASCII/ANSI, mal mit CIFS (siehe oben).

NetBEUI/SMB

NetBEUI ist das um SMB erweiterte alte NetBIOS. SMB kann mit ASCII/ANSI oder CIFS oder Unicode arbeiten (siehe oben).

Tabelle 2.2: Vorherrschende Zeichensätze und ihre Verwendungsformen (Forts.)

Die Ergebnisse von Filterversuchen sind bei den verschiedenen »Marktführern« der LAN-Analyse verschieden deprimierend. Der Verfasser kennt keinen einzigen Analyzer, der die verschiedenen Zeichensatz-Konvertierungen vollständig und korrekt durchführen würde. Schon die Suche nach einem NetBIOS-Namen wie SERVER-01 erbringt oft nur ein Viertel oder die Hälfte aller wirklich gegebenen Fundstellen. Da muss man sich wirklich fragen, welchen Sinn es hat, teures Geld für »Expertensysteme« auszugeben, die noch nicht einmal in der Lage sind, zuverlässig nach allen Paketen zu suchen, die einen bestimmten Maschinennamen enthalten. Es kann nicht verwundern, dass hier wieder auf TraceMagic verwiesen wird. Sobald TraceMagic erkennt, dass nach einer Textfolge oder einem Maschinennamen gesucht wird, wird automatisch abgefragt, welche Zeichensätze bei der Filtersuche berücksichtigt werden sollen (oder eben nicht). Das Ganze geht aber noch weiter. Es stellt sich die Frage, in welchen Protokollen Maschinennamen auftreten können, und hier ist die Zahl der möglichen Protokolle so groß, dass unmöglich eine vollständige Übersicht möglich ist. ■ ■ ■ ■

NetBIOS (in allen Varianten, darunter NetBEUI und NetBT) SMB (was streng genommen unter NetBEUI fällt) NetWare SAP (Service Advertisement Protocol) NetWare SLP (Service Location Protocol)

>>> NEW TECH

77

Kapitel 2 • LAN-Analyzer in der Kritik

■ ■ ■ ■ ■ ■ ■ ■ ■ ■

NetWare Bindery-Abfragen via NCP (NetWare Core Protocol) NetWare NDS-Abfragen (NetWare Directory Services) RPC (Remote Procedure Call, in der Unix-Welt verbreitet) WINS (Windows Internet Name Service) DNS (Domain Name Service) DHCP (Rückgabe des Domain-Namens und des Host-Namens an den Client) Cisco-Layer-2 Management Notifications (über LLC) MS-ADS (Active Directory Service) AppleTalk-Protokolle (allerdings inzwischen kaum noch verwendet) ... und so weiter und so weiter.

In allen diesen Protokollen kommen Maschinennamen vor und das in allen denkbaren Zeichensätzen und Kombinationen. In SMB-Paketen können sich sogar die Zeichensätze abwechseln. Wie soll ein Filter funktionieren, der keine automatische Konvertierung des gesuchten Maschinennamens in die verschiedenen Zeichensätze vornimmt? Der Aufwand ist zwar erhöht, weil ggf. jedes einzelne Datenpaket bis zu viermal durchsucht werden muss (nämlich je Zeichensatz einmal), aber das Ergebnis ist dann akkurat und nicht etwa unvollständig. Hier scheitern alle Analyzer in erheblichem Ausmaß. Wer immer die Probe aufs Exempel macht, wird am Ende nur noch den Kopf schütteln.

2.14.3 Online-Filter versus Offline-Filter Es stellt sich die Frage, woher gravierende Einschränkungen wie die oben beschriebenen stammen. Eine der Antworten lautet: Offline-Filter sind ganz oder weitgehend identisch mit Online-Filtern, was ihre Fähigkeiten anbetrifft. Da während der OnlineAnalyse, die oft zugleich mit dem sog. Capturing verbunden ist (dem Mitlesen und Speichern der LAN-Pakete), einfach zu wenig Zeit besteht, zwischen zwei eingehenden Datenpaketen komplizierte Methoden anzuwenden, beschränkt sich die Funktionalität auf das Wesentliche. Das ist, für die Online-Filter betrachtet, völlig richtig. Die paar Nanosekunden, die zwischen zwei LAN-Paketen auf der Leitung verfügbar sind, lassen kaum Zeit für umfangreiche Prüfungen. Für die Offline-Filter jedoch wäre es richtig gewesen, nicht genau dieselben Methoden anzuwenden, sondern Erweiterungen vorzunehmen, so unter anderem die Konvertierung zwischen verschiedenen Zeichensätzen.

78

>>> NEW TECH

Das Scheitern beim Filtern

Aus der Arbeitsökonomie des Programmierers heraus ergibt sich sicherlich, dass es einfacher ist, jeweils nur eine einzige Ablaufroutine je Zweck in den Programmbibliotheken zu hinterlegen. Aus dem Interesse des Anwenders heraus jedoch, zu zweifelsfreien und vollständigen Ergebnissen zu gelangen, ist diese Vorgehensweise nicht nachvollziehbar, sondern vielmehr unbefriedigend und wegen der Gefahr falscher Diagnosen sogar gefährlich. Aber das war nicht alles. Eine wichtige Rolle spielt hierbei die Unfähigkeit der LAN-Analyzer, in der Offline-Bearbeitung der Trace-Daten jeweils mehr als nur eine Aufzeichnungs-Datei zu untersuchen.

2.14.4 Online-Filter als Ersatz für beschränkte Offline-Filter Die Offline-Filter leiden bei allen Analyzern unter der höchst dramatischen Beschränkung, dass sie immer nur Anwendungen auf genau die LAN-Pakete finden, die in einer einzigen Aufzeichnungs-Datei abgespeichert sind. Wenn aber (was nicht unrealistisch ist) nach ein paar Stunden schon über 1.000 Trace-Dateien auf der Festplatte gespeichert sind (sagen wir mal: in der Größe von jeweils 32 MB), so ist schnell einzusehen, ■

■

dass es völlig unmöglich ist, jede der vielen Trace-Dateien manuell in das Expertensystem einzuladen (über den DATEI-ÖFFNEN-Dialog) und sodann per Filter zu untersuchen; dass es völlig unmöglich ist, bei dem daraus folgenden Stichprobenprinzip noch zu repräsentativen Ergebnissen zu kommen.

»Stichprobenprinzip« bedeutet: Mit jeder einzelnen Trace-Datei wird nur ein winziges Zeitfenster des insgesamt aufgezeichneten Messzeitraums untersucht. Wenn nicht gerade zufällig die genaue Uhrzeit einer Störung bekannt ist, kann der Anwender kaum aus hunderten oder tausenden von Trace-Dateien die just richtige herausfinden (mittels der Zeitangabe, da ja jede Datei das Datum ihrer Erzeugung in sich trägt). Und auch ein solcher glücklicher Zufall setzt voraus, dass zur Zeit der Störung auch die Ursachen sichtbar sind – was oft abwegig ist, denn nicht selten ereignen sich die Ursachen späterer Störungen früh morgens beim Booten und bei der Anmeldung an der Domain. Was also tut der LAN-Analyst in dieser Lage? Er setzt einen Online-Filter und zwar mit folgender Überlegung: Der Analyzer läuft ja den ganzen Tag mit, somit deckt der Filter die gesamte Messdauer ab und somit werden auch alle Ereignisse gefunden, die durch den Filter als Treffer identifizierbar sind. Dieses Verfahren leidet jedoch unter massiven Einschränkungen: ■

Online-Filter machen blind gegenüber allem anderen, was da sonst noch unterwegs war. Man stelle sich das Dilemma vor: Man setzt einen Filter in Erwartung, dass bestimmte Ereignisse einen Hinweis geben würden auf vermutete Fehler. Jetzt sammelt der Filter Trefferpakete ein, aber man kann

>>> NEW TECH

79

Kapitel 2 • LAN-Analyzer in der Kritik

■

nicht mehr erschließen, in welchem Gesamtzusammenhang die Trefferpakete unterwegs waren! Nur leider: Es ist sodann zu spät, um den Restverkehr noch nachträglich einzufangen. ... Will sagen: Online-Filter sind hoch problematisch, wenn sie (zu) eng definiert sind und sie sind meistens (zu) eng definiert. Was geschieht, wenn die Chance zu weiterer Online-Arbeit nicht gegeben ist? Beispiel: Ein Kunde (Anwender) hat mit seinem Analyzer einen ganzen Tag lang die LAN-Pakete aufgezeichnet; er kam danach in der Betrachtung zu keinem hinreichenden Ergebnis; er sendet nunmehr die Messdaten auf CD-ROM zu seinem Service-Partner mit der Bitte, sich die Daten anzusehen. Was soll der Dienstleister tun? Er kann eigentlich nur hoffen, dass er mit manuellen Stichproben zum Erfolg kommt. Das aber ist in der Zeit der Gigabit-Backbones praktisch unmöglich geworden.

Im Ergebnis kann das nur bedeuten: ■

■

■

Eine Analyse-Software muss in der Lage sein, auch nachträglich – also offline – die aufgezeichneten LAN-Pakete vollständig zu untersuchen: und seien es auch 10 oder 20 oder 50 Gigabyte an Trace-Files. Diese Analyse-Software muss zudem in der Lage sein, wenigstens bei einfachen Filtern sehr schnell zu arbeiten, um erträgliche Bearbeitungszeiten zu gewährleisten. Immerhin ist leicht nachvollziehbar, dass ein Filter, der beispielsweise 10 Gigabytes Messdaten, verteilt auf 250 Trace-Dateien, zu verarbeiten hat, in akzeptabler Zeit fertig sein muss. Etwas anders sieht es aus bei der komplexen Kombination mehrerer Filter; hier weiß jeder, dass Geduld unerlässlich ist. Die Filter müssen sämtliche Erfordernisse der Format-Konversion berücksichtigen, wie sie oben mit Beispielen für IP-Adressen, Textfolgen und Maschinennamen aufgeführt wurden.

Es gibt nach Kenntnis des Verfassers nur eine einzige Software, die das leisten kann: und das ist TraceMagic, das eigens hierfür spezielle, hoch leistungsfähige Funktionen bietet. TraceMagic ist in der Lage, aus fast beliebigen Mengen von AufzeichnungsDateien die gewünschten Pakete herauszufiltern. Der schöne Vorteil daran ist: Die Online-Leistung des Analyzers wird nicht beeinträchtigt, alles wird bei der Online-Messung mitgenommen und also kann nach dem Offline-Filtern jederzeit wieder auf die Gesamtmenge der im LAN gesendeten Pakete zurückgegriffen werden (da ja alle LAN-Pakete während der Messung auf die Festplatte gebracht wurden). So und nur so lassen sich revisionsfähige bzw. repräsentative Ergebnisse via Filter erreichen.

80

>>> NEW TECH

Das Scheitern des Stichprobenprinzips

2.15 Das Scheitern des Stichprobenprinzips Alle bisher besprochenen Maßnahmen der Analyse gehen stillschweigend von folgenden Voraussetzungen aus (immer aus der Sicht der bekannten LANAnalyzer): ■ ■

■

■

■

Nur bei der Online-Messung können lange Zeiträume mit Aussagen abgedeckt werden. Bei der Offline-Bearbeitung der Messdaten verkürzt sich die Analyse auf winzige Zeitfenster, nämlich jeweils auf den kurzen Zeitraum, der sich in Form von LAN-Paketen in einer einzigen Aufzeichnungs-Datei (Trace-File, Capture-File) abbildet. Online reicht die Zeit nicht für umfangreiche bzw. komplizierte Auswertungsmethoden. Nur verhältnismäßig einfache Statistiken oder Ereignisse können erarbeitet und dargestellt werden. Offline wäre die Zeit für umfassendere Auswertungen zwar da, aber die betrachteten Zeiträume sind zu kurz (weil immer nur eine einzige TraceDatei zur selben Zeit vom Expertensystem bearbeitet werden kann). Somit reduziert sich das gesamte Analyse-Verfahren auf das Auswerten von Stichproben oder anders gesagt: Entweder wird auf analytische Tiefe verzichtet (online) oder auf die Bearbeitung langer Zeiträume (offline).

Es soll nicht verkannt werden, dass die Hersteller durchaus Beachtliches geleistet haben. Einer der letzten großen Schritte war die Erlangung der Fähigkeit, mit einem so genannten Software-Analyzer auch auf Gigabit-Leitungen vollwertige Ergebnisse zu erzielen (hier ist aus Sicht des Verfassers insbesondere der Hersteller WildPackets mit seinem Produkt EtherPeek NX hervorzuheben). Das alles soll nicht gering geschätzt werden. Und doch muss Kritik fällig werden, wo die Mängel überhand nehmen.

2.15.1 Nicht gelöst: Das Problem »giga«-großer Datenmengen bzw. langer Aufzeichnungszeiträume Alle Hersteller haben Jahre lang geschlafen und versäumt, sich auf die wachsenden Datenmengen einzustellen. Vor zehn Jahren hat der Verfasser dieser Zeilen noch einen ganzen Tag lang den kompletten LAN-Verkehr von einem Ethernet-Koax abgreifen können, ohne dass bei vielleicht 200 Anwendern mehr als 200 Megabyte an Messdaten zusammengekommen wären. (Es sei daran erinnert, wie sparsam z.B. Word-4 unter DOS mit Ressourcen umging.) Schon unter Fast Ethernet jedoch kamen auf Backbone-Leitungen pro Tag ein paar Gigabyte an Messdaten zusammen.

>>> NEW TECH

81

Kapitel 2 • LAN-Analyzer in der Kritik

Heute, auf Gigabit-Leitungen im Backbone großer Campus-LANs, kommen pro Tag durchaus 20-100 GB an Messdaten zusammen! Die Zahl der TraceDateien kann (bei voller Aufzeichnung aller Pakete, ohne Filter, ohne Längenbeschränkung der Frames) auf weit über 10.000 ansteigen. Wie soll – bitte schön – unter solchen Bedingungen weiter mit einer AnalyzerArchitektur gearbeitet werden, die allen Ernstes verlangt, dass der Anwender einzelne Trace-Dateien über den DATEI ÖFFNEN-Dialog in das Expertensystem seines Analyzers einlädt!? Das ist schlicht und einfach unter den gegebenen Umständen alles andere als eine angemessene, praktikable Lösung.

2.15.2 Nicht gelöst: Das Problem nur spontan auftretender Fehler Es ist aber nicht nur eine Frage der Datenmengen, sondern auch der Fehlerhäufigkeit. Wenn Fehler nicht regelmäßig auftreten (also nicht mit hinreichender Häufigkeit) und wenn sie sich auch nicht durch gezieltes Handeln hervorrufen lassen, so spricht man gemeinhin von sporadisch auftretenden Fehlern. Ob der Fehler wirklich nur sporadisch auftritt oder ob er möglicherweise ständig da ist, aber nur spontan vom Menschen wahrgenommen wird, bleibt dabei zunächst außen vor. Die Frage lautet schlicht und einfach: Wenn ein Fehler nach der Beobachtung der Menschen nur spontan auftritt und wenn seine Charakteristik keine hilfreichen Rückschlüsse bzw. Hypothesen zulässt über Ursache und Hergang: was ist dann zu tun? Wie soll man sich dem messtechnisch nähern? Die Antwort hierauf lautet: Es bleibt nichts anderes übrig, als eine Dauermessung anzusetzen, die Stunden, ja Tage durchlaufen kann; und dann, wenn ein Anwender sicher ist, den Fehler wieder erlebt bzw. beobachtet zu haben, wird die Aufzeichnung des LANAnalyzers beendet und die bis dahin aufgezeichneten LAN-Pakete werden untersucht. Gemeinhin wird dabei so verfahren, dass der Anwender, der die Meldung gab, gebeten wird, die möglichst genaue Uhrzeit der Störung bekannt zu geben, damit mittels der Datei-Zeitstempel die Zahl der Trace-Dateien eingeschränkt werden kann, die manuell zu untersuchen sind. Dieses Verfahren der Nachbearbeitung ist unter vielerlei Gesichtspunkten unzuverlässig: ■ ■

82

Die Zeitangabe des Anwenders kann unzuverlässig sein. Selbst dann, wenn die Zeitangabe stimmt, ist völlig ungewiss, ob neben der Wirkung des Fehlers (der Anwender nimmt ja die Wirkungen wahr) zur selben Zeit auch die Ursache auf der Leitung war.

>>> NEW TECH

Das Scheitern des Stichprobenprinzips

■

■

Selbst dann, wenn alle diese zweifelhaften Bedingungen zutreffen, ist noch offen, ob alle zum Ablauf gehörenden Pakete auch in ein und derselben Trace-Datei zu finden sind. Denn: Wenn sich die zu einem Fehlerablauf gehörenden Pakete auf mehrere TraceDateien verteilen, ist in aller Regel damit zu rechnen, dass die Expertensysteme der LAN-Analyzer den Ablauf nicht mehr als Ganzes bewerten können. Die Fähigkeit, den Ablauf als fehlerhaft zu charakterisieren, kann dabei ganz oder teilweise verloren gehen.

Es ergibt sich also, dass eine Arbeitsweise zu wählen ist, die alle diese Mängel nicht aufweist. Es ist jeweils schlicht vom Gegenteil auszugehen, um zu einer erfolgreichen Methode zu kommen: ■

■

■

Auf die Zeitangabe des Anwenders darf es am Ende nicht mehr ankommen. Sie ist zwar immer hilfreich, darf aber nicht Voraussetzung für das Gelingen sein. Die Messung muss einen so langen Vorlauf gehabt haben, dass man sicher davon ausgehen kann, dass auch die Ursache des Fehlers »im Kasten« ist (also mitaufgezeichnet wurde). Dies bedeutet in der Praxis, dass die Messung vor Arbeitsantritt der Mitarbeiter begann – und dass somit schon das Booten der Maschinen am Morgen in den Aufzeichnungen festgehalten ist. Somit könnte ein später am Tag aufgetretener Fehler ggf. auf fehlerhafte Abläufe in der sensiblen Startzeit am Morgen zurückgeführt werden (sofern die nächste Bedingung erfüllt ist). Weiterhin müsste die Analyse-Software in der Lage sein, den gesamten Aufzeichnungszeitraum (mehr oder weniger) als Ganzes zu betrachten. Die Datei-Grenzen der Trace-Files dürfen dabei nur eine möglichst geringe Rolle spielen. Die Software muss es also schaffen, hunderte von Dateien und Millionen von LAN-Paketen in einem einzigen Durchgang zu untersuchen, zu bewerten und per Bericht greifbar zu machen.

Damit ist das Arbeitsprinzip von TraceMagic im Kern beschrieben. In der Praxis läuft das oft auf ein völlig simples Verfahren hinaus: ■

■

Morgens wird der Analyzer am Messpunkt aktiviert, wird die Aufzeichnung aller LAN-Pakete gestartet, die an diesem Messpunkt vorbei kommen (kein Filter, keine Längenbeschränkung der Pakete im Aufnahme-Puffer). Der Analyzer läuft den ganzen Tag mit. Selbst, wenn schon bald ein Anwender sagt, er habe den Fehler beobachtet, wird bis abends weiter mitgelesen und aufgezeichnet. Die Gründe hierfür sind leicht nachvollziehbar: Wenn man von vornherein davon ausgeht, mit einer Auswertungs-Software zu arbeiten, der es (fast) egal ist, welche Datenmengen man ihr übergibt, so kann man auch in Ruhe bis zum Ende des Tages warten. Weiterhin verlängert die Messdauer die Wahrscheinlichkeit, dass der Fehler ein weiteres Mal auftritt und mit jedem weiteren Auftreten steigt die Wahrscheinlichkeit, eine saubere und vollständige Diagnose stellen zu können.

>>> NEW TECH

83

Kapitel 2 • LAN-Analyzer in der Kritik

■

■

Abends wird die Aufzeichnung beendet. Sodann wird TraceMagic gestartet, d.h. die Auswertung der gesammelten Messdaten wird begonnen. Das kann in aller Ruhe über Nacht geschehen. Am nächsten Morgen liegen alle Reports vor, sei es als lesbare Text-Datei, als verarbeitungsfähige CSV-Datei (Excel), als abfragbare Datenbank oder als chronologisches Verlaufsprotokoll der Ereignisse.

Jedoch muss hier gleich bemerkt werden: Niemand wird gezwungen, bis zum nächsten Morgen zu warten. Wer sicher ist, dass die Meldung des Anwenders über Tage sicher zum erwarteten Fehler passt, bricht eben schon tagsüber die Aufzeichnung ab und beginnt mit der Massenauswertung mittels TraceMagic. Entsprechend kleiner ist eben die Datenmenge, entsprechend schneller ist die Auswertung fertig. Es ist auch möglich, einen »Schuss ins Blaue« vorzunehmen und TraceMagic nur diejenigen Trace-Dateien zur Verarbeitung zu übergeben, die ungefähr den vom Anwender angegebenen Zeitraum abdecken. Vielleicht bildet sich ja tatsächlich in einem solcher Art verkürzten Zeitfenster bereits das gesamte Geschehen ab – und falls nicht, bleibt immer noch genügend Gelegenheit, die Totalauswertung aller Trace-Dateien anzustoßen. Zur Kritik der bekannten LAN-Analyzer: Für ein solches Szenario bieten sie nicht den kleinsten Ansatz einer Lösung. Ihnen fehlen alle Mittel, die für ein solches Vorgehen nötig sind.

2.16 Das Scheitern bei Verifikations-Analysen Was sind Verifikations-Analysen bzw. Verifikations-Messungen? Hierzu gibt es zwei Erklärungen: 1. Ein vorliegender Befund soll überprüft werden. Es soll also aus den vorhandenen Messdaten heraus eine neuerliche, unabhängige Bewertung abgeleitet werden, um die Gültigkeit des ersten Befundes zu überprüfen. 2. Nach einer ersten Messung sind Veränderungen im Netzwerk erfolgt: Router wurden neu konfiguriert, Server verändert, Clients angepasst. Nach diesen Eingriffen möchte der Kunde bzw. Netzwerk-Admin wissen: Sind die Fehler zuverlässig weg? Kommen sie auch nicht wieder? Jetzt (nach ein paar Wochen oder Monaten) steht also an, dieselbe Messung zu wiederholen und die Ergebnisse zu vergleichen, wobei die zentrale Frage ist, ob sich die früher festgestellten Fehler erneut nachweisen lassen (oder eben nicht).

84

>>> NEW TECH

Das Scheitern bei Verifikations-Analysen

2.16.1 Fragen bzw. Bedingungen für eine erfolgreiche Verifikation Für beide Formen der Verifikation stellen sich theoretische und praktische Fragen: Wie kann sichergestellt werden, dass bei der zweiten Untersuchung exakt dieselben Methoden angewendet werden wie bei der jeweils vorangegangenen Untersuchung? Denn: Weichen die Vorgehensweisen voneinander ab, so kann die Gültigkeit zumindest eines Vergleichs schnell von jedermann in Zweifel gezogen werden. Insbesondere Hersteller von Hardware und Software verstehen sich gut darauf, tausend und zwei Gründe dafür zu finden, warum angeblich ein Messergebnis nicht aussagekräftig sein soll. Die Identität der Methoden ist also für die Unanfechtbarkeit der schließlich herauskommenden Ergebnisse unverzichtbar. ■ Wie kann sichergestellt werden, dass auch Fehler, die nur (noch) höchst selten auf der Leitung sind, sicher nachgewiesen werden? Oder anders ausgedrückt: Wie kann neben dem Positiv-Nachweis der Fehleranwesenheit auch der Negativ-Nachweis der Fehlerabwesenheit zuverlässig und unanfechtbar erbracht werden? Die Antwort darauf lautet: Die Analyse-Methode muss in der Lage sein, Stunden oder gar einen ganzen Tag komplett und ausnahmslos zu untersuchen und zu bewerten. Einen Rückzug auf Stichproben darf es nicht geben. Insbesondere der zuletzt angesprochene Punkt weist auf eine Achillesferse der heutigen Analyzer hin: Sie können zwar mit Glück und den richtigen Stichproben die Anwesenheit eines Fehlers nachweisen, aber nicht die Abwesenheit. ■

Denn um die Abwesenheit eines Fehlers zuverlässig nachweisen zu können, muss über einen langen Zeitraum hinweg (bei dem die Aufzeichnungen ohne Filter, ohne Einschränkungen stattfanden) der Totalbefund über eine schier unendlich große Menge aller denkbaren bzw. möglichen Fehler geliefert werden. Ein solches Ausschlussverfahren ermöglichen die heutigen Analyzer jedoch nur mit Bezug auf einfache Aussagen, etwa: »Es wurden keine ICMP-Meldungen von Routern gesehen.« »Es wurden keine Retransmissions festgestellt.« Wenn man bedenkt, dass sich Fehler weit jenseits solcher simpel nachweisbaren Ereignisse zutragen können (siehe oben, Beispiele zu Fehlern in den DateiDiensten), wird schnell klar, dass mit solch einfältigen Methoden keine sicheren Befunde zu erheben sind. Weiterhin ergibt sich hieraus (wieder einmal), warum der Verfasser dieses Buches irgendwann keine Lust mehr hatte, auf die bekannten Hersteller zu warten, und irgendwann war TraceMagic da, mit dem alle diese Möglichkeiten gegeben sind.

>>> NEW TECH

85

Kapitel 2 • LAN-Analyzer in der Kritik

2.16.2 Hilfreich, aber bei Analyzern nicht vorhanden: ein »Gedächtnis« (Datenbank) Die bislang bekannten Analyzer verfügen zudem nicht über ein eigenes »Gedächtnis«, um frühere Untersuchungen bzw. deren Ergebnisse auf den Bildschirm zurückzuholen bzw. um die früher bereits angewendeten Methoden 1:1 auf eine spätere Wiederholung der Untersuchung übertragen zu können. Im weiteren Fortgang des Buches wird das Thema »Datenbank« mit den speziellen Unterthemen von »History-Datenbank« und »Knowledgebase« noch eingehend behandelt werden.

2.17 Das Scheitern mangels Datenbanken Was soll das sein, ein »Gedächtnis« für Analyzer? Nun, das ist verhältnismäßig einfach zu sagen. Folgende Fähigkeiten sollte ein Analyzer (oder eine Auswertungs-Software) haben, um dauerhaft größtmöglichen Nutzen stiften zu können: ■ ■

■

■

Filter müssen in einer Datenbank abzulegen, konfigurierbar und letztlich auch kommentierbar sein. Analyse-Methoden bzw. Abläufe bestimmter Untersuchungen müssen in einer History-Datenbank abgespeichert werden, um jederzeit rekonstruierbar, aber auch reproduzierbar zu sein. Alle Analyse-Vorgänge, Filter und Suchmuster müssen beliebigen Themen zugeordnet werden können, um gemäß dieser Zuordnung auch wieder abgefragt werden zu können. Als »Thema« in diesem Sinne kann gelten: der Name eines Kunden (etwa Dream Company/Dream City); die Bezeichnung für ein Subnetz (etwa Vorstandsetage); die Bezeichnung für einen Messpunkt (etwa Cisco 6000/Etage 4); die abstrakte Bezeichnung eines Stör-Szenarios (etwa Routingfehler oder Name Service-Fehler). Durch die Möglichkeit, nach solchen Merkmalen in der Datenbank gezielt zu suchen, werden Anwender in die Lage versetzt, entweder gezielt oder aber intuitiv nach verschiedenen Analyse-Einträgen zu suchen. Eine Wissens-Datenbank (»Knowledgebase«) muss schon seitens des Herstellers gut mit Hinweisen zur Fehlerfindung und -beseitigung ausgestattet sein; sie muss aber auch die Möglichkeit bieten, dass die Anwender die Datenbank nach und nach um eigenes Wissen und um eigene Erfahrungen erweitern können.

Es bedarf keiner langatmigen Prüfung, um zu erkennen, dass die bekannten Analyzer solche Arbeitsformen nicht unterstützen. Das hat geradezu absurde Folgen: ■

86

Lösungswege müssen jedes Mal wieder neu entwickelt werden, weil sie nicht aus Datenbanken abrufbar sind.

>>> NEW TECH

Das Scheitern bei der Berichtsausgabe

■

■

Komplizierte Filterkombinationen oder Filterabfolgen, die sich mit den simplen Mitteln der Analyzer nicht abbilden bzw. abspeichern lassen, müssen immer wieder neu zusammengebaut werden. Lösungswissen kann nicht von einem Anwender auf den nächsten übertragen werden – wenigstens nicht mit den Mitteln des Analyzers. (Das hindert natürlich die Anwender nicht, sich in wöchentlichen Selbsthilfegruppen zu organisieren, um ihr Erfahrungswissen auszutauschen.)

Man kann den Gedanken auch anders aufgliedern und einfach mal fragen: Welche Berechtigung hat ein Analyzer samt Expertensystem, ■ ■ ■

... wenn nur das vorgegebene Wissen des Herstellers darin Platz findet, ... wenn aber nicht das Erfahrungswissen der Anwender aufgenommen werden kann, ... wenn, allgemeiner ausgedrückt, nicht das Wissen um spezifische Umgebungsbedingungen aufgenommen werden kann?

Denn es ergibt schon einen Unterschied (und zwar einen sehr deutlichen Unterschied), ob beispielsweise TCP Retransmissions massiv an einem HTTP-Server oder aber an einem Oracle-Datenbank-Server auftreten. Oder es ergibt einen Unterschied, ob bestimmte Zugriffsfehler von WindowsClients in Abhängigkeit von Service-Packs beobachtet werden (oder nicht). Oder es ist erheblich zu wissen, welche Script-Zeilen am Login-Server vorhanden sein müssen, um bestimmte Zugriffsfehler von Clients zu vermeiden. Alles das ist der typische Stoff einer Wissens-Datenbank. Und ein Analyzer, der Fehler aufzeigt, aber das lokale Lösungswissen bzw. Umgebungswissen nicht aufnehmen (und dann bei Bedarf wieder ausgeben) kann, ist schlichtweg nicht voll lösungsfähig. Denn das Lösungswissen steckt eher in den Köpfen der lokalen Techniker und Admins, nicht in den Köpfen der Analyzer-Programmierer. Warum wiederum die Hersteller der Analyzer die Kunden gewissermaßen dumm halten, indem sie ihnen nicht die Möglichkeit geben, eine eigene Wissens-Datenbank aufzubauen, ist nicht erschließbar. Klar ist nur, dass die Analyzer keine Möglichkeiten dieser Art bieten. Damit werden aber rund 50% des zu Diagnose und Therapie nötigen Wissens ausgeblendet oder doch behindert: das Wissen der vor Ort tätigen Techniker und Admins.

2.18 Das Scheitern bei der Berichtsausgabe Ganz zuletzt sollte es immer eines geben: einen klugen Befund auf einem Blatt Papier, ein Bericht, ein Report, ein auswertbares Ergebnis. Auch hiermit haben die meisten Produkte ihre Schwierigkeiten.

>>> NEW TECH

87

Kapitel 2 • LAN-Analyzer in der Kritik

2.18.1 Wie es (leider) bei den LAN-Analyzern ist Hat je ein Analyzer vollständige Berichts-Dateien ausgegeben, ■ ■ ■ ■

teils für Menschen lesbar, teils in geeigneter Software weiter verarbeitbar (CSV -> Excel), teils über Datenbanken abfragbar, teils über die Analyzer selber verifizierbar?

Nichts – oder doch nur wenig davon (CSV-Dateien) – wird von den heute bekannten Analyzern ausgegeben. Es scheint den Herstellern nicht wichtig zu sein; sie scheinen nicht zu wissen, in welcher Situation sich die LAN-Analysten befinden. Was tut der Mensch, von Überstunden geplagt? Er sitzt Stunden oder Tage vor seinem Laptop, womöglich noch im Keller des Rechenzentrums, bei abgekühlten 13 Grad Celsius (alles schon dagewesen!), und übernimmt Screenshots der Analyzer-Darstellung in Word-Dateien, um daselbst Dutzende dieser bunten Bilder mit eigenen Worten zu kommentieren. Am Ende gibt es 100 oder 200 Seiten, voll gestopft mit vielen Bildern und wenigen Worten, und das Ganze soll dann geeignet sein, komplizierte Wechselwirkungen darzustellen und der mögliche Leser (der es nicht frühzeitig geschafft hat, sich krank zu melden), soll dann in der Lage sein, sich da durchzukämpfen und das Ergebnis zusammengefasst wiederum an Dritte weiterzugeben? Das ist unmenschlich, unzuverlässig, unsinnig und am Ende kommt ein »Stille Post«-Prinzip heraus: Einer erzählt dem anderen etwas weiter und der Letzte in der Kette weiß womöglich schon gar nicht mehr, wovon da ursprünglich wohl mal die Rede gewesen sein könnte.

2.18.2 Wie stattdessen gearbeitet werden sollte (TraceMagic) Die korrekte Alternative zu dieser sehr speziellen Form der Sprachlosigkeit besteht darin, ■ ■

automatisch komplette Berichtswerke zu erstellen (bis hin zu umfangreichen Ergebnis-Datenbanken, die unter verschiedener Hinsicht abfragbar sind), jedem interessierten Dritten diese Daten zur Verfügung stellen zu können – samt einem »Viewer«-Modul, mit dem alle diese Ergebnisse schnell, einfach und zielgerichtet überflogen, gelesen, abgefragt oder weiterverarbeitet werden können.

Nichts davon bieten die bekannten Analyzer (oder nur rudimentäre Ansätze dazu). TraceMagic wurde unter anderem dazu entwickelt, die komplette Berichtsweitergabe zu ermöglichen samt der Betrachtung beim Empfänger durch ein »Viewer«-Modul, das lizenzfrei ist (also kein Geld kostet) und in dieser Art dem bekannten Acrobat Reader ähnelt, mit dem zwar PDF-Dateien gelesen, aber nicht erzeugt oder verändert werden können.

88

>>> NEW TECH

Das Scheitern bei der Berichtsausgabe

2.18.3 Effizienz der Berichtsweitergabe = Effizienz der Ergebnisumsetzung Die Effizienz der Berichtsweitergabe entscheidet wesentlich darüber, wie schnell und zuverlässig die Ergebnisse im Sinne der Fehlerbeseitigung umgesetzt werden. Oder um es medizinisch auszudrücken: Die Verfügbarkeit und Verständlichkeit der Diagnose für Dritte beeinflusst unmittelbar die Bereitschaft und Fähigkeit, in die gezielte Therapie einzutreten. Wie oft wurde nicht in der Vergangenheit (und wird heute immer noch) das üble Spiel »Schwarzer Peter« gespielt: ■ ■ ■

Keiner will’s gewesen sein, aber alle haben Schlaues zu vermelden und ansonsten hoffen alle, dass der Kelch vorübergehen möge.

Das kann es doch wohl nicht gewesen sein!?

2.18.4 Berichtswesen, Arbeitsteilung und -organisation Hier muss Bezug genommen werden auf die nicht immer einfache Arbeitsteilung rund um EDV und Datenkommunikation. Immerhin greifen die verschiedensten Instanzen und Abteilungen ineinander: ■ ■

Vertikal: Vorstand, Abteilungsleiter, Techniker Horizontal: Abteilungen, externe Dienstleister, Lieferanten

Alle müssen koordiniert werden; alle müssen vor Eintritt in die Therapie dem Befund der Diagnose zugestimmt haben (oder doch wenigstens auf Einspruch verzichtet haben); alle müssen wissen, was zu tun ist. Wie soll das angehen, wenn Ergebnisse, die mit dem Analyzer erhoben wurden, mehr oder weniger nur nach Hörensagen vermittelt werden können? Denn es kann ja wohl nicht allen Ernstes behauptet werden, ■ ■

dass immer alle gleichzeitig während der Online-Messung um den Bildschirm herumstehen und die Online-Anzeigen verfolgen, dass immer alle hinterher die umfangreichen Word-Dateien mitsamt ihrer bunten Screenshots durchlesen?

Hier entstehen Reibungsverluste, welche die Unternehmen viel Geld kosten, viel Zeit, viel Nerven, viel Reaktionsfähigkeit. Nichts davon ist letztlich hinnehmbar. Die Alternative ist:

>>> NEW TECH

89

Kapitel 2 • LAN-Analyzer in der Kritik

2.18.5 LAN-Analyse als permanente Qualitätssicherung (proaktiv statt reaktiv) Richtig kann nur die folgende Arbeitsweise sein: ■ ■ ■

■

Eine zentrale Stelle betreibt ständig LAN-Analyse und das fast vollständig automatisiert. Von dieser zentralen Stelle aus werden die Ergebnisse an einen fest definierten Empfängerkreis weitergeleitet. Alle Empfänger können über ein »Viewer«-Modul die Ergebnisse unkompliziert und schnell, aber eben auch in aller Tiefe und Gründlichkeit durchsehen und ggf. sogar weiterverarbeiten. Der Rücklauf der Berichtsempfänger kann sodann in der Zentrale in die Analyse-Datenbank aufgenommen werden, um für spätere Verifikationen, aber auch für zukünftige Störfälle eine möglichst breite Faktenbasis zu schaffen.

In einer solchen Organisationsform wandelt sich LAN-Analyse zur permanenten Qualitätssicherung und es wird nicht mehr nur re-aktiv dem Chaos hinterher gelaufen, sondern es wird stattdessen pro-aktiv in steter Vorbeugung praktisch ausgeschlossen, dass sich Fehler im Stillen nach und nach aufbauen und aufschaukeln können. Selbstverständlich muss die Fähigkeit zu schneller Reaktion in einem akuten Störfall beibehalten werden; das steht außer Frage. Aber es soll doch mehr und mehr der Schwerpunkt verlagert werden auf eine ständige Beobachtung des Netzwerkes und der darin ablaufenden Kommunikation. Die üblichen LAN-Analyzer bieten hierzu nur eingeschränkte Ansätze. Das Konzept, mit den Online-Expertensystemen die aktuellen Fehler schon im laufenden Betrieb zu erkennen und anzuzeigen, ist zwar nicht falsch, scheitert aber in der Praxis an folgenden Einschränkungen bzw. Randbedingungen: ■

■

■

90

Nur verhältnismäßig simple Fehler und Ereignisse werden erkannt und angezeigt, etwa ICMP-Meldungen oder TCP Retransmissions. Das ist zu wenig und außerdem sind solche Ereignisse lediglich die Wirkung einer Ursache, die gleichwohl weiter im Dunklen bleibt. Wirkungen, die als Fehler erlebt werden, haben ihre Ursachen oft Minuten oder Stunden vor der wahrgenommenen Störung. Online-Expertensysteme können bei solchen Zeiträumen keine Aufklärung bieten, sie bewegen sich in ihrer Logik nur in extrem kleinen bzw. kurzen Zeitfenstern. Die Online-Expertensysteme zeigen lediglich auf dem Analyzer-Monitor ihre Ergebnisse vollständig an, Berichte in Form von Dateien, Tabellen oder Datenbanken werden nur höchst eingeschränkt ausgegeben. Damit jedoch vermindert sich der Wert ihrer Befunde insgesamt drastisch: Denn was nützen bunte Bilder auf dem Monitor, wenn sie nicht Dritten nachträglich zugänglich gemacht werden können?

>>> NEW TECH

Das Scheitern bei der Berichtsausgabe

Diese Einschränkungen sprechen nicht wirklich gegen den Einsatz der bekannten Online-Expertensysteme, sie sprechen aber sehr wohl gegen falsche Hoffnungen, die allgemein mit ihnen verbunden werden. Weiterhin unternehmen Netzwerk-Admins den Versuch, mit den Mitteln des klassischen Netzwerk-Managements die laufende Sicherheit und Qualität der Datenkommunikation zu überwachen. Dabei kommen Werkzeuge zum Einsatz wie zum Beispiel: ■ ■ ■ ■ ■

HP Open View (Hewlett Packard) What's Up Gold (IpSwitch) Ntop (FreeWare) Cisco Works (Cisco) ... und dergleichen mehr.

Auch das alles ist nicht falsch. Der Ausfall eines Switches, die Überlastung eines Routers sind dadurch in aller Regel schnell und sicher erkennbar. Aber schon viele Routing-Fehler auf IP-Ebene und Dialogereignisse auf TCP-Ebene lassen sich mit solchen Mitteln nicht mehr erkennen, geschweige denn in Berichtsform festhalten und ausgeben. Auch hier gilt: Der Einsatz dieser Mittel ist korrekt und auch unverzichtbar. Falsch wäre nur, sich von ihnen Hilfe zu erwarten, die sie nicht gewähren können. In den folgenden Kapiteln, in denen die aktuellen Fehler der heutigen Netzwerk-Landschaften erklärt und Nachweismittel von TraceMagic dargelegt werden, wird für den Leser schnell nachvollziehbar sein, wieso diese Kritik an den LAN-Analyzern und auch den Mitteln des klassischen Netzwerk-Managements nicht etwa übel wollende Krittelei ist, sondern die Grundlage für eine berechtigte und sogar fundamentale Neu-Orientierung in der Art und Weise, Fehlern vorbeugend und nacharbeitend zu begegnen.

>>> NEW TECH

91

Kapitel 3 LAN-Analyzer: Anmerkungen Dieses kurze Kapitel soll einige der Analyzer kurz beleuchten, mit denen der Verfasser in den letzten zwei Jahren seit dem ersten Erscheinen seines Buches Networker’s Guide. LAN Analysis und Windows Troubleshooting Berührung hatte. Es haben sich nicht wenige Bewertungen verschoben. Da der Verfasser nur mit wenigen Werkzeugen ernsthaft arbeitet (weil er den Rest für ziemlich untauglich hält), ist dieser Überblick alles andere als repräsentativ, aber sicherlich aufschlussreich, was die Bewertungskriterien im Sinne von Analyse und Troubleshooting anbetrifft.

3.1 Software-Analyzer Kurz gefasst: Seitdem EtherPeek NX auf Gigabit-Leitungen hervorragende Ergebnisse beim Capturing erbringt, sind für den Verfasser die Hardware-Analyzer für echte Fehlersuche bzw. für Troubleshooting nur noch zweite, wenn nicht gar dritte Wahl. Entsprechend fallen hier auch die Bewertungen grundsätzlich zu Gunsten der Software-Analyzer aus.

3.1.1

LANdecoder32 (Triticom)

Als Erstes sei der LANdecoder32 von Triticom (www.triticom.com) erwähnt, da fast alle Beispiele im Networker’s Guide (Erste Auflage München 2000, Markt+Technik) mit Abbildungen dieses Analyzers illustriert worden waren – und weil der Verfasser sich fast ausnahmslos zu diesem Analyzer bekannt hatte, als dem damals besten im Sinne unbeschränkter Navigation und übersichtlicher Darstellung. Diese Bewertung lässt sich heute in dieser Form nicht mehr aufrecht erhalten und zwar aus einigen wenigen, aber stichhaltigen Gründen: ■

Erstens wurde das Experten-System des LANdecoder32 durch TraceMagic komplett überholt und dadurch in vielen (nicht allen!) Funktionen praktisch weitgehend überflüssig. Das gilt aber auch für die Experten-Systeme aller anderen Analyzer.

>>> NEW TECH

93

Kapitel 3 • LAN-Analyzer: Anmerkungen

■

■

■

Zweitens wurde die Protokoll-Dekodierung für NCP-über-TCP/IP nicht mehr nachgepflegt. Es kann sein, dass Triticom zu der Ansicht gelangte, dieser Markt sei inzwischen zu klein, um noch der Mühe wert zu sein; und doch fehlt dieses Decoding, wenn Messungen in einer NetWare-Umgebung anstehen. Drittens hat Triticom kein Commitment abgegeben zur Zuverlässigkeit des Capturings unter Gigabit-Bedingungen. War das so genannte AccuCapture unter Fast Ethernet noch ein unbedingter Grund, LANdecoder32 einzusetzen (da die Zuverlässigkeit bzw. die niedrige Paketverlustrate dafür sprachen), so fehlt nun die Entsprechung für Gigabit (Stand: Oktober 2002). Zwar gibt Triticom eine Liste der unterstützten Gigabit-Adapter heraus, aber gemessen am »AccuCapture« unter 100-Megabit-Bedingungen ist dies ein Rückschritt. Viertens fehlen weitere wichtige Entwicklungen wie beispielsweise die Unterstützung von WLANs (Wireless LANs).

Ansonsten aber zählt der LANdecoder32 immer noch zu »Papas Lieblingen« (also zu den vom Autor bevorzugten Produkten), denn seine Art der Darstellung, seine Navigation über die LAN-Pakete, seine Filtermöglichkeiten sowie seine Farbgebung sind nach wie vor in der Kategorie »best of ...« anzusiedeln. Daher sind weiterhin die Darstellungen von Paket-Dekodierungen zahlreich mit dem LANdecoder32 erstellt worden. Ansonsten sei hier auf einen zweiten Analyzer verwiesen, der nach Meinung des Verfassers weit aufgeschlossen hat (was Navigation, Darstellung etc. anbetrifft) und bei Gigabit-Messungen sogar die Nase vorne hat: Das ist EtherPeek NX von WildPackets (siehe unten).

3.1.2

Observer (Network Instruments)

Der Observer von Network Instruments (www.networkinstruments.com) hat sich erstaunlich weit entwickelt. Seine statistischen Fähigkeiten sind inzwischen womöglich die besten im Kreise der kommerziellen Analyzer und die jüngsten Fortschritte bezüglich Voice over IP machen den Observer im Umfeld von Sprach-Daten-Netzen sogar (fast) unverzichtbar. Außerdem sind die Fähigkeiten zu verteilter Überwachung (Remote Monitoring über RMON und proprietäre Entwicklungen) in der Bedienerfreundlichkeit kaum zu schlagen. Das kann aber nicht verdecken, dass neben der Mächtigkeit der Statistik die Qualität der Analyse nicht Schritt halten konnte. Darstellung, Navigation, Filterfähigkeiten und Farbgebung sind noch nicht einmal durchschnittlich gut und die Möglichkeiten, sich mit Observer völlig unbekannten Fehler-Szenarien zu nähern, sind aus Sicht des Verfassers mehr als bescheiden.

94

>>> NEW TECH

Software-Analyzer

Andererseits gilt auch hier (wie bei allen anderen), dass dieser Mangel inzwischen aber auch nicht mehr weh tut, weil jenseits der Statistik die Fehler-Analyse sowieso über TraceMagic abgewickelt wird – und nicht mehr über den Analyzer, der die Daten von der Leitung holte. Da der Verfasser die Ansicht vertritt, dass kein Werkzeug alles kann und dass Statistik sowie Analyse jeweils ihre eigene Berechtigung haben, gilt im Ergebnis: Der Observer gehört in jedes Netzwerk, sollte aber nicht mit Erwartungen in der Analyse überfordert werden, denen er auf Grund seiner Architektur nicht gerecht werden kann. Schnelle Übersicht aber über (fast) alles, was sich quantifizieren bzw. in Statistiken erfassen lässt, gibt der Observer (fast) perfekt.

3.1.3

EtherPeek NX (WildPackets)

Das EtherPeek NX (www.wildpackets.com) ist der Shooting Star der Jahre 2001/ 2002 und das in mehrerlei Hinsicht: Erstens sind Messungen auf Gigabit-Leitungen mit EtherPeek NX eine wahre Wonne (hier kann des Lobes nicht genügend ausgesprochen werden) und zweitens beginnt hier eine Software zu wachsen, die dem bislang vom Verfasser bevorzugten LANdecoder32 wohl bald den Rang ablaufen könnte. Navigation, Darstellung und Paket-Dekodierung sind inzwischen weitgehend gleichwertig (verglichen mit LANdecoder32). Wo noch Wünsche offen sind: Das Filtern ist leider noch nicht im finalen Entwicklungsstadium angekommen. Hervorragend sind die Fähigkeiten, Paket-Dekodierungen in HTML-Format auszugeben, und schlicht überwältigend ist das Gigabit-Verhalten: Schon Anfang 2002 hat WildPackets das Commitment (die Zusage im Sinne der Gewährleistung) abgegeben, dass bis zu ca. 60% Netzlast auf der GigabitLeitung bei hinreichend schnellem Prozessor des Analyzers (fast) verlustfreies Capturing möglich sei. Der Verfasser hat mit seinem Unternehmen Synapse:Networks viele GigabitMessungen auch auf hart befahrenen Leitungen hinter sich und er kann bestätigen: Dieses Werkzeug hält, was es verspricht. Als LAN-Adapter wird zur Zeit (in 2002) eine SysConnect-GE-Karte genommen. Manchmal wirklich atemberaubend ist die Fähigkeit, auch bei Volldampf ein schnell, zuverlässig und zugleich sanft arbeitendes Online-Experten-System arbeiten zu lassen, das über alle einfachen Fehler schnelle Auskunft gibt, entweder sortiert nach Fehlerklassen, oder sortiert nach Teilnehmeradressen oder Dialogpaaren. Der Verfasser kann nicht verhehlen, im Sommer 2001 derlei Leistungen eines »Software-Analyzers« für glatt unmöglich gehalten zu haben – er wurde eines Besseren belehrt. Voraussetzung ist jedoch eine großzügige Hardware-Ausstat-

>>> NEW TECH

95

Kapitel 3 • LAN-Analyzer: Anmerkungen

tung des Messrechners, der über viel Hauptspeicher, schnellen RAM-BUS und extrem schnelle Festplatte verfügen sollte (siehe hierzu: www.staccer.de). Und wird der Preis noch in die Betrachtung einbezogen, ergibt sich das gute Gefühl, auch in Gigabit-Backbones eine sichere Technik in der Hand zu haben. Neben EtherPeek (Ethernet) gibt es auch noch TokenPeek (Token-Ring) und neuerdings auch AeroPeek (Wireless LANs). Die Breite der Produktpalette überzeugt hier ebenso wie die Entwicklungsdynamik und das Preis-LeistungsVerhältnis.

3.1.4

Sniffer (NAI, vormals Network General)

Sniffer bzw. SnifferPro (www.sniffer.com) ist nach wie vor an der Spitze der Entwicklung, wenn es um die Implementation neuer Protokolle geht. Wer darauf angewiesen ist, immer möglichst aktuell mit allen neuen Protokollvarianten (um nicht zu sagen: Protokoll-Exoten) versorgt zu sein, wird auf Sniffer schlecht verzichten können. Ansonsten scheiden sich beim Sniffer für viele Netzwerk-Admins die Geister. Verglichen mit der Leistungskraft anderer Analyzer, sogar FreeWare-Tools bzw. Open Source-Programmen, muss der Preis dem Zweifel unterworfen werden, womöglich nicht ganz angemessen zu sein. Aus der Sicht des Verfassers ist spätestens seit TraceMagic bei Sniffer ernstlich die Frage zu stellen, ob der Hersteller sein Preis-Leistungs-Verhältnis nicht intensiv überdenken sollte. Aber dies mögen subjektive Eindrücke eines Spezialisten sein, der die Bedürfnisse eines Gelegenheits-Analysten nicht mehr genau nachvollziehen kann. Denn es gibt durchaus Sniffer-Anwender, die nur ab und zu LAN-Analyse betreiben und denen nach eigenem Bekunden durchaus mit dem Experten-System des Sniffers geholfen werden konnte. Der Verfasser muss also in seinem Urteil vorsichtig sein, trotzdem will er nicht verbergen, dass er die Verbreitung im Markt und das Preis-Leistungs-Verhältnis des Sniffers nie verstanden hat. Zum historischen Verständnis sei der Hinweis gegeben, dass der heutige Windows-Sniffer weitgehend auf dem NetXRay von Cinco beruht (in den 90-er Jahren aufgekauft). Das Aufzeichnungsformat des heutigen Sniffers mit seinen .CAP-Dateien ist das alte NetXRay-Format.

3.1.5

Surveyor (Shomiti-Finisar)

Der Surveyor von vormals Shomiti, jetzt Finisar (www.finisar.com), gehört zu den Produkten, die sowohl als Software-Analyzer einsetzbar sind wie auch als Front-End von Hardware-Lösungen.

96

>>> NEW TECH

Software-Analyzer

Die so genannte THG-Box (»Ten Hundred Giga«) von Shomiti-Finisar war in 2001 über einige Zeit ernstlich ein Kandidat für leistungsfähige Gigabit-Messungen und entsprechend wäre der Surveyor ein Werkzeug der engeren Wahl gewesen. Ausgiebige Tests von THG und Surveyor im Herbst 2001 erbrachten jedoch Schwächen in der Hardware, die letztlich nicht hinnehmbar waren und als dann Shomiti von Finisar übernommen wurde, war leider zunächst nicht mehr klar, ob und wohin die zukünftige Entwicklung gehen würde. Aber auch unabhängig davon ist festzustellen: Es macht nicht so viel Sinn, immer nur winzige Zeitfenster von der Leitung abgreifen zu können, wenn nach 256 Megabyte der Hardware-Puffer voll ist und sodann erst derselbe ausgelesen werden muss. ... Hier zeigt EtherPeek NX (WildPackets), wie man’s richtig macht: ständiges Schreiben auf die Festplatte praktisch ohne nennenswerte Paketverluste. Es mag sein, dass inzwischen die Schwächen behoben wurden, und es kann sein, dass Finisar die Entwicklung weitertreibt, aber das alles ist aus Sicht des Verfassers nicht mehr maßgeblich. Seitdem mit EtherPeek NX (WildPackets) zu einem fast schon lächerlichen Preis eine extrem leistungsfähige Gigabit-Capture-Engine auf den Markt gebracht wurde, dürften die Tage der so genannten Hardware-Analyzer endgültig gezählt sein: zu teuer, zu langsam in der Produktentwicklung, zu riskant mit Blick auf das verlorene Investment, wenn sich Fehler in der Hardware bemerkbar machen. Dies ist, wohl gemerkt, das subjektive Urteil des Verfassers. Niemand sollte darauf verzichten, ggf. durch Tests zu einem eigenen und anderen Urteil zu kommen. Der Verfasser jedoch glaubt, für diese Sicht der Dinge gute Gründe zu haben. Ergänzend jedoch muss zu Gunsten der Finisar-Produkte festgestellt werden, dass die extrem teure Entwicklung von Gigabit-Komponenten hier ziemlich ernst genommen zu werden scheint. Die Möglichkeiten, Hardware-Probes in Gigabit-Backbones an Stelle der zu wenig leistungsfähigen RMON-Agenten einzusetzen, sind durchaus beachtlich: Der Einsatz der Surveyor-Software verhilft in diesem Umfeld zu akzeptablen Ergebnissen bei Distributed Remote Monitoring. Es müssen jedoch schon sehr spezielle Echtzeit-Anforderungen gestellt werden, um das erhebliche Investment in diese gehobene Technik zu rechtfertigen.

3.1.6

Ethereal

Mit Ethereal (www.ethereal.com) ist ein Analyzer unter GPL-Lizenz auf den Markt getreten, der zum Teil über Funktionen verfügt, die extrem leistungsfähig sind und die man bei den kommerziellen Mitbewerbern vergeblich sucht.

>>> NEW TECH

97

Kapitel 3 • LAN-Analyzer: Anmerkungen

Dass er sowohl unter Unix als auch unter Windows läuft, gibt diesem Analyzer eine universelle Note, die in der Praxis wichtig sein kann. Vor allem die Möglichkeiten des Anwenders, eigene Nutzungsformen zu konfektionieren, sind nicht gering zu schätzen. Ethereal spielt für den Verfasser und sein TraceMagic-Konzept eine große Rolle. TraceMagic unterstützt die meisten der gängigen Analyzer-Formate und somit ist es inzwischen völlig belanglos geworden, welcher Analyzer als CaptureEngine die Daten von der Leitung geholt hat und wenn das nun schon einmal egal ist, kann es eben auch ein Open-Source-Tool sein. Im Februar 2002 stellte der Verfasser über einen seiner Kunden Kontakt zu den Programmierern von Ethereal her und hierdurch wurde veranlasst, dass Ethereal die Fähigkeit bekam, Messdaten fortlaufend in sequenziellen TraceDateien auf die Festplatte zu schreiben. Diese Möglichkeit war bis Anfang 2002 weder gegeben noch vorgesehen (so die Auskunft eines der Programmierer noch im Januar 2002 gegenüber dem Verfasser). Der Umstand, dass diese Fähigkeit zum Schreiben der Messdaten in TraceDateien auf die Anzahl von zehn Capture-Files begrenzt wurde, lässt allerdings ahnen, dass nach der im Herbst gültigen Version 0.95 die irgendwann kommende Version 1.0 kommerziell vertrieben werden könnte. Denn wozu sollte die Zahl der Trace-Files beschränkt sein, wenn nicht zu dem Zweck, für eine Aufhebung dieser Beschränkung später Geld zu nehmen? Aber das ist Spekulation. Sicher ist, dass mit Ethereal ein erheblicher Schritt nach vorne getan wurde, um den Capture-Job wenigstens auf 10/100 Megabit von teuren Markenprodukten unabhängig zu machen.

3.1.7

TcpDump

Diese Freeware (www.tcpdump.org) ist ähnlich interessant wie Ethereal. Beide Produkte verbindet, dass Ethereal erheblich angelehnt ist an TcpDump. TcpDump arbeitet in seiner Capture Engine mit dem libcap-Treiber, der auch in anderen Open Source-Programmen verwendet wird. Der Verfasser hat mit folgender Konstellation gute Erfahrungen gemacht: ■

■

98

Ein Unix-Server ist mit einem ATM-Adapter oder mit einem Gigabit-Ethernet-Adapter ans Netzwerk angeschlossen und Messung über Mirror-Port ist nicht möglich. Statt einen ATM-Tester zu bemühen (wovon der Verfasser schlicht gar nichts hält) oder die Gigabit-Ethernet-Konstruktion so weit umzubauen, dass irgendwo ein GE-Mirror-Port frei wird, wird TcpDump auf dem ServerAdapter gestartet.

>>> NEW TECH

Hardware-Analyzer

■ ■ ■

TcpDump erzeugt Aufzeichnungs-Dateien, wie es ein Analyzer auf der Leitung auch tun würde: MAC-Header, IP, TCP, alles ist korrekt vorhanden. Nach Beendigung der Messung werden die Trace-Dateien auf den TraceMagic-Rechner kopiert. Sodann wertet TraceMagic die Aufzeichnungs-Dateien automatisch aus.

Dieses Verfahren gibt ein so immens hohes Maß an Unabhängigkeit von der Verfügbarkeit von Messpunkten im Backbone, dass es sich schon als universal einstufen lässt. Theoretisch gibt es ähnliche Möglichkeiten auf Windows-Servern, hier aber liegen noch keine Erfahrungen des Verfassers vor (WinPCap-Treiber). Auch hiermit ist ein weiterer Schritt in die Richtung getan, sich von kommerziellen Produkten unabhängig zu machen, wenn es um Capture-Engines geht.

3.1.8

NTOP

Als FreeWare-Capture-Engine kommt auch NTOP in Frage (www.ntop.org). Dieses Werkzeug verfügt auf Unix/Linux-Basis über immense Fähigkeiten in Statistik, Monitoring, Datenfluss-Kontrolle, Verkehrs-Matrix und so weiter. Die Leistungsfähigkeit dieses Werkzeuges ist in manchen Bereichen so stark, dass man durchaus Gründe für die Überzeugung finden kann, dass kommerzielle Windows-Analyzer womöglich nur deshalb so erfolgreich sind, weil zu wenig Netzwerk-Admins mit Unix und Open Source-Software umgehen können. Mit NTOP lassen sich umfangreiche Maßnahmen des Netzwerk-Monitorings durchführen. Ein Packet-Capture ist bislang nur rudimentär möglich. Trotzdem soll hier NTOP erwähnt werden, weil sich eine zukünftige Entwicklung in diese Richtung abzuzeichnen beginnt. In jedem Falle sind die Statistik-Fähigkeiten schon heute so stark, dass LANAnalyzer für teures Geld hierfür nicht mehr zweckentfremdet werden müssen.

3.2 Hardware-Analyzer Kurz vorab gesagt: Hardware-Analyzer sind aus Sicht des Verfassers für die klassische LAN-Analyse eine Technik von gestern (von wenigen Ausnahmen abgesehen, wie etwa die tragbaren Geräte von Fluke). Diese Aussage bezieht sich nicht auf Monitoring-Systeme, wie sie beispielsweise bei Internetprovidern oder Betreibern von Voice over IP laufen. Gemeint sind Systeme, die vorgeben, »LAN-Analyse« zu betreiben mit der Fähigkeit zu Fehlerdiagnose und Ursachenerkennung.

>>> NEW TECH

99

Kapitel 3 • LAN-Analyzer: Anmerkungen

Seitdem EtherPeek NX (WildPackets) auf Gigabit-Leitungen hervorragende Ergebnisse mit seiner Capture Engine erbringt, gibt es keine ernstlichen Gründe mehr dafür, so viel Geld für die doch sehr teuren Hardware-Boliden aufzuwenden. Tests mit Gigabit-Hardware-Analyzern, die der Verfasser im Herbst 2001 sehr ausführlich angestellt hatte, offenbarten das nicht geringe Risiko, dass schon kleine Fehler in der Hardware das ganze Investment lahm legen. Rücksendung, Austausch, Warten ... das kann nicht hingenommen werden. Die nachfolgenden Bewertungen müssen aber von jedem Leser im Zweifel durch eigene Tests nachvollzogen werden. Unter veränderten Anforderungen (die ja nicht dieselben wie die des Verfassers sein müssen) können auch andere Urteile die Folge sein.

3.2.1

Hardware-Hersteller begehrt TraceMagic-Code

Eine Anekdote muss hier vorangestellt werden, weil sie die Hilflosigkeit dieser Hersteller geradezu beispielhaft aufzeigt: Es hat im Frühjahr 2002 Verhandlungen zwischen einem der unten aufgeführten Analyzer-Hersteller einerseits und Synapse:Networks andererseits gegeben (dem Unternehmen des Verfassers). Gegenstand war die Portierung von TraceMagic-Analyse-Funktionen in die Analyzer-Suite des besagten Herstellers (der auf eigenen Wunsch hin in den Publikationen des Verfassers anonym bleiben möchte). Nach mehreren Wochen hat der Verfasser die Verhandlungen entnervt abgebrochen – mit dem höchst unerfreulichen Eindruck, dass die Gegenseite sowohl vertragstechnisch wie auch analysetechnisch völlig hilflos bzw. überfordert und daher im Grunde überhaupt nicht verhandlungsfähig war. Wenn man einem angeblichen Marktführer erst noch das kleine Einmaleins der LAN-Analyse und der Client/Server-Diagnostik erklären muss, ergeben solche Gespräche irgendwann einfach keinen Sinn mehr – so jedenfalls die Wahrnehmung des Verfassers. Als an einem Punkt der Gespräche der Analyzer-Vertreter etwas beleidigt war, weil der Verfasser die TCP/IP-Analyse-Funktionen der Gegenseite nicht recht wertschätzen wollte, und als der dortige Verhandlungsführer stolz auf sein mageres Dutzend an Schwellwerten bzw. Statistik-Zähler in diesem Bereich verwies (zehn oder elf Zähler zu IP, UDP, TCP, ICMP), konnte nicht der Hinweis unterbleiben, dass TraceMagic schon seit längerer Zeit mit über 200 Fehlerund Ereignis-Zählern bei der TCP/IP-Analyse arbeitet, und das sowohl im Bereich der Gesamtstatistiken (over all hosts) sowie für jeden einzelnen von bis zu 65.500 IP-Hosts (per single host). Warum nur verhandelte dieser Hersteller mit Synapse:Networks, wenn er dann eingeschnappt war, dass bzw. wenn TraceMagic bereits in völlig anderen Dimensionen arbeitet(e)? Irgendwann muss man sich doch mal entscheiden, was man will.

100

>>> NEW TECH

Hardware-Analyzer

Die Software besagten Herstellers zeichnete sich zudem durch dramatische Mängel aus, so beispielsweise beim Filtering. Es war wirklich kaum zu fassen. Filter auf NetBIOS-Namen erbrachten zum Teil weniger als die Hälfte der tatsächlich vorhandenen Fundstellen. Aber sagen durfte man das nicht, da war die Gegenseite gleich beleidigt. Da fehlen einem am Ende wirklich die Worte – spätestens dann, wenn man die Preise sieht, die dieser Hersteller bis heute nimmt.

3.2.2

Agilent (Hewlett Packard)

Agilent ist eine Tochter von Hewlett-Packard, spezialisiert auf LAN-Messtechnik (www.agilent.com). Im Herbst 2001 wurde der vormals Internetwork Advisor genannte, jetzt schlicht nur Network Analyzer genannte Verbund von Hardware und Software getestet. Damals waren die Ergebnisse nicht überzeugend. Im Frühjahr 2002 wurde die Software erneut getestet und wieder konnte das Ergebnis nicht zufriedenstellen. Die Zeitfenster, die das Experten-System betrachten konnte, waren einfach zu klein (zu kurz), um zuverlässig zu umfassenden Aussagen zu kommen und es waren Fehler festzustellen, die in einem so hochpreisigen Produkt einfach nicht vorkommen dürfen. Aus Sicht des Verfassers ist auch hier die Zeit über das Konzept der HardwareAnalyzer hinweggegangen.

3.2.3

Acterna (Wavetech Wandel Goltermann)

Acterna ist die Analyse-Tochter der Firma Wavetech-Wandel-Goltermann (www.acterna.com). Die Acterna-Software konnte in den letzten zwei Jahren nur ein einziges Mal vom Verfasser kurz betrachtet werden, ein hinreichendes Urteil liegt daher nicht vor.

3.2.4

Shomiti-Finisar

In 2001 wurde Shomiti von Finisar übernommen (www.finisar.com). Was im Wesentlichen zu den LAN-Analyse-Produkten von Shomiti-Finisar zu sagen war, ist oben unter dem Stichwort Surveyor angeführt worden (Abschnitt »Software-Analyzer«). Es sei noch der Hinweis erlaubt, dass Shomiti-Finisar als Hardware-Lieferant von Fluke durchaus Verdienste in der Entwicklung von leistungsfähigen AnalyseASICs sowie passender Software erworben hat.

>>> NEW TECH

101

Kapitel 3 • LAN-Analyzer: Anmerkungen

3.2.5

NetTool (Fluke)

Fluke (www.flukenetworks.com) hat sich das Verdienst erworben, akzeptable tragbare Geräte zu entwickeln, die robust sind, mobil und die mit verhältnismäßig geringem Schulungsaufwand in den Einsatz gehen können. Schon allein die miniaturisierten NetTool-Kästchen sind für Feldtechniker eine immense Erleichterung, weil auch Personal, das in LAN-Analyse nicht sonderlich geschult ist, in überschaubaren, einfachen Standardtests zu wichtigen Grundaussagen kommen kann. Gemessen jedoch an ausgereiften Analyse-Lösungen müssen auch hier Zweifel am Preis-Leistungs-Verhältnis erlaubt sein. Ansonsten jedoch läuft Fluke einigermaßen außer Konkurrenz, weil die Konzeption dieser Monitoring- und Analyse-Technik deutlich anders ist als bei klassischen LAN-Analyzern.

3.2.6

NetVCR (NikSun)

Mit NetVCR (www.niksun.com) ist ein Produkt auf dem Markt, das eine Klasse für sich darstellt und hier unbedingt erwähnt werden muss. NetVCR ist kein üblicher Analyzer, es handelt sich vielmehr um ein Monitoring- und Archivierungs-System, dessen Grundgedanke wie folgt aussieht: ■ ■

■

■

Der gesamte LAN-Traffic wird archiviert, entweder auf Festplatten und/ oder Streamer-Tapes (daher der Name »VCR«). Über die gesammelten, gespeicherten Daten werden in Echtzeit Tabellen, Indizes und Statistiken geführt, die per Fernzugriff via HTTP (Webbrowser) abgerufen werden können. Insbesondere Online-Broker, Banken und Börsenmakler können durch diese Totalarchivierung Schutz vor Beschuldigungen erlangen, ihre Online-Systeme wären zum Zeitpunkt X nicht verfügbar gewesen. Beliebige Zeitabschnitte aus dem Endlosarchiv können nachträglich rekonstruiert, ausgewertet und statistisch verarbeitet werden. Die LAN-Pakete beliebiger Zeitfenster lassen sich aus dem Archiv sogar in Trace-Dateien ausgeben (Sniffer-Format), was wiederum die nachträgliche Totalauswertung mittels TraceMagic ermöglicht.

Die Systeme sind nicht eben billig, aber immens leistungsfähig und gewissermaßen eine Art von Lebensversicherung: Wenn 24 Stunden am Tag, sieben Tage die Woche, die Totalarchivierung läuft, kann bei jedem beliebigen Störfall der Datenverkehr aus dem Archiv heraus kopiert und gründlich untersucht werden. Findet diese Untersuchung über TraceMagic statt (da TraceMagic selbstverständlich das Sniffer-Format unterstützt, das von NetVCR verwendet wird), ist praktisch kaum noch möglich, dass selbst spontan auftretende Fehler ohne Aufklärung bleiben. 102

>>> NEW TECH

Kapitel 4 LAN-Analyse: Neue Wege Es ist schnell ersichtlich, dass die bisherigen Wege der LAN-Analyse nicht mehr zum gewünschten Erfolg führen. Wichtige Entwicklungen wurden verschlafen, das heißt unter Gigabit-Bedingungen sind die herkömmlichen Analyse-Methoden nur noch höchst eingeschränkt geeignet, ihren Zweck zu erfüllen.

4.1 Wandel der LAN-Analyse Die LAN-Analyse hat sich in Art und Umfang in den letzten zehn Jahren mehrfach verändert (Stand: 2002). Hier spielt eine Rolle, welche Vorgaben die Hersteller mit ihren Produkten machen, aber es ist auch von Belang, in welcher Vorstellungswelt die Netzwerk-Admins leben und arbeiten. Sowohl in der Leistungsfähigkeit der Produkte, aber auch in den Erwartungen und Fähigkeiten der Anwender haben sich in der Betrachtung des Verfassers erhebliche Veränderungen vollzogen, während gleichzeitig andernorts geradezu Stillstand zu verzeichnen ist, nämlich in einigen Punkten der System-Architektur der LAN-Analyzer. Hierauf soll in diesem Kapitel eingegangen werden, ■ ■ ■

um die Veränderungen der Analyzer zu bewerten, um die Bedeutung der menschlichen Vorstellungen zu bewerten, um beides mit den heutigen Anforderungen zu koordinieren.

Es sollen also auch die Voraussetzungen einer fürs Unternehmen sinnvollen Analyse-Umgebung erörtert werden.

4.2 Die wichtigsten Stationen aus zehn Jahren Die augenfälligsten Stationen dürften im Großen und Ganzen diese (gewesen) sein: ■

Ende der 80-er und Anfang der 90-er Jahre waren DOS-Analyzer vorherrschend, mit denen hauptsächlich defekte Koax-Kabel im Ethernet-Bereich oder andere Fehler in den OSI-Schichten 1 und 2 erkannt wurden. Expertensysteme waren noch nicht erfunden, allenfalls standen einfache Hilfetexte zur Verfügung.

>>> NEW TECH

103

Kapitel 4 • LAN-Analyse: Neue Wege

■

■

■

■

■

■

■

Mitte der 90-er Jahre kamen die ersten leistungsfähigen Windows-Analyzer auf den Markt. Auffällig war, dass der Marktführer Sniffer auf den Zukauf von NetXRay angewiesen war, um den Weg in die Windows-Welt gehen zu können. Die ersten Expertensysteme, die diesen Namen verdienten, kamen ebenfalls Mitte der 90-er Jahre auf. Physikalische Fehler und einfache Ereignisse der Schichten 3 (Routing) und 4 (Transport bzw. Dialogkontrolle) können passabel schon online erkannt bzw. angezeigt werden. Da die Physik der Netze durch Abbau der letzten Koax-Kabel und IBMTyp-1-Kabel erheblich zunahm, verminderte sich seit Mitte der 90-er Jahre der Druck, Analyzer zur Überwachung der LAN-Hardware einzusetzen. Der Schwerpunkt verlagert sich auf höhere Schichten, ohne aber auf dem Application Layer zu nennenswerten Erfolgen zu führen. Der Wegfall von Shared Media (Koax, Typ-1) bzw. die Verbreitung der Switches führt am Ende dazu, dass nur noch geringe Teilausschnitte des gesamten Netzes »gesehen« werden können. Dies führt(e) bis heute zu Versuchen, mit RMON (oder proprietären Derivaten) eine Netzwerk übergreifende Statistik bzw. Analyse zu ermöglichen. Im Bereich der Statistik ist dies zum Teil hervorragend gelungen, im Bereich der Analyse sind die Versuche in den Ansätzen stecken geblieben. »Distributed Analysis« lautet das Zauberwort, das jedoch weitgehend in der Praxis auf Statistik hinausläuft, nicht aber auf echte Analyse. Spätestens Ende der 90-er Jahre bzw. zu Beginn der 2000-er Jahre haben sich die Unternehmen so stark auf EDV und LAN/WAN eingelassen, dass die Verfügbarkeitsanforderungen praktisch allerorts bei 100% liegen. Die Verfügbarkeitssicherung wird allgemein mit den klassischen Mitteln des Netzwerk-Managements angestrebt; LAN-Analyse wird allgemein erst dann eingesetzt, wenn bereits Fehler aufgetreten sind. Gigabit-Ethernet verlangt eine deutlich erhöhte Leistungsfähigkeit der Analyzer. Es zeichnen sich erst Abstände zwischen den Herstellern bzw. der Zuverlässigkeit ihrer Produkte unter Gigabit-Bedingungen ab. Ende 2002 (bei Abfassen dieses Buches) gilt, dass in aller Regel weiterhin der klassische LAN-Analyzer nur punktuell bzw. nur sporadisch eingesetzt wird, nicht aber flächendeckend, und eher re-aktiv als pro-aktiv. Wichtige Fehlerursachen und -Wechselwirkungen werden von den Produkten der Marktführer nicht erkannt. Es gilt das Stichprobenprinzip, lang laufendes Screening (Analyse über lange Zeiträume) ist nicht möglich.

Diese kleine Zeitleiste zeigt, dass sich die Probleme verschoben haben und dass sich die Umgebungsbedingungen (Gigabit, Switches, Verfügbarkeitsvorgaben) erheblich geändert haben. Wir werden der Frage nachzugehen haben, mit welcher Technik, mit welcher Konzeption und mit welcher Ausbildung der Anwender LAN-Analyse in den nächsten Jahren erfolgreich leisten kann.

104

>>> NEW TECH

Die Ausbildung der LAN-Analysten

4.3 Die Ausbildung der LAN-Analysten Dieser Abschnitt wird sicherlich von manchem Leser mit Spannung verfolgt werden: Denn wer dieses Buch liest, wird schon mal einen LAN-Analyzer in der Hand gehabt haben. Was denkt der Verfasser von Ihnen, dem Leser und Praktiker vor Ort? Im Einzelnen lautet die Antwort natürlich: Es ist völlig unmöglich, den »durchschnittlichen LAN-Analysten« zu kennen, denn den gibt es gar nicht, und dazu müsste der Verfasser tausende von Ihnen, werte Leser, interviewt haben. Aber das ist hier auch gar nicht Ziel und Zweck der Besprechung. Es gibt ein paar Beobachtungen, die der Verfasser über alle Jahre immer wieder gemacht hat, und diese Beobachtungen scheinen sich im Laufe der Zeit bewahrheitet zu haben. Wir sprechen hier weniger über den einzelnen Analysten (was, wie gesagt, gar nicht ginge), sondern mehr über die typischen Bedingungen, unter denen Analysten arbeiten bzw. eingesetzt werden, und diese Bedingungen lassen durchaus allgemeine Bewertungen zu, die von erheblicher Bedeutung sind für die Frage: Wie werden wir die LAN-Analyse in den nächsten Jahren organisieren? Hier folgen nun also ein paar der Beobachtungen, die der Verfasser für das aktuelle Thema für wichtig hält: ■

■

■

■

Was früher tatsächlich einmal »Netzwerk-Analyse« war und daher folgerichtig auch von Netzwerk-Technikern geleistet wurde, ist heute mehr und mehr zur »Endgeräte-Analyse« oder »Transaktions-Analyse« mutiert. Trotzdem sind immer noch die Netzwerk-Techniker zuständig – einfach, weil sie schon immer zuständig waren und weil sie den physikalischen Zugang zur LAN-Leitung haben. Netzwerk-Techniker sind jedoch keine Windows-Admins, Unix-Admins, Applikations-Betreuer, Datenbank-Designer, sie sind Netzwerk-Techniker. Ihnen fehlen folglich wichtige Kenntnisse zur Bewertung von Vorgängen auf den Schichten 4-7 (Transport, Application, Name Services etc.). Selbst dann, wenn Windows-Admins mit dem LAN-Analyzern Fehlern ihrer Windows-Umgebung auf der Spur sind, zeigt sich mit erheblicher Häufigkeit, dass die allgemein durchlaufenen Seminare, die im Mircosoft- bzw. Windows-Umfeld abgehalten werden, nicht das ausreichende Wissen vermittelt haben, um die etwas komplizierteren Fehler (aber darum nicht untypischen Fehler!) zuverlässig und hinreichend schnell zu erkennen und auf die gegebenen Ursachen zurückzuführen. Selbst dann, wenn die Ausbildung gut und die Seminare tauglich waren, unterstützt meistens der vorhandene LAN-Analyzer die erforderliche Fehlersuche nicht (oder nicht genug), weil wiederum die Programmierer der Hersteller entweder zu wenig Kenntnis vom aktuellen Sachverhalt hatten oder weil sie aus sonstigen Gründen gehindert waren, ihre Expertensysteme in der geforderten Weise auszurüsten. Die Folge: Der Anwender (hier unser

>>> NEW TECH

105

Kapitel 4 • LAN-Analyse: Neue Wege

■

Windows-Admin) sieht nicht die ganze Wirklichkeit, sondern nur einen verkürzten Ausschnitt. »Was der Analyzer nicht zeigt, gibt’s auch nicht«, könnte man das im Ergebnis auch nennen. Im schlechtesten Fall führt dies zum bekannten Schwarzer Peter-Spiel, wenn mehrere Techniker und Admins, alle in der beschriebenen misslichen Lage, gemeinsam feststellen, es auch nicht so genau zu wissen. Im besten Fall wird zwar das gewünschte Ergebnis irgendwann erreicht, aber es hat dann unangenehm lange gedauert.

Der Verfasser will also niemandem auf den Schlips treten – er will vielmehr seine Beobachtung mitteilen, dass oft aktuelle Probleme von den falschen Leuten gelöst werden sollen. Es käme ja auch niemand auf die Idee, bei einem Schaden am Kühlschrank den Fernsehtechniker zu holen. Und der Kühlschranktechniker käme nicht auf die Idee, mit einem Schlagbohrer die Lösung des Kühlproblems zu suchen. Es arbeiten viel zu oft im Bereich der »Netzwerk-Analyse« viele Menschen aneinander vorbei: Ein Anwender beklagt sich, dass es langsam gehe. Schon steht der Satz im Raum: »Das Netzwerk ist langsam« oder »Der Server tut’s nicht«. Das ist genau so, als würde Folgendes geschehen: Ein braver Bürger dieser Republik in Castrop-Rauxel betritt abends sein Wohnzimmer, betätigt den Lichtschalter, und es bleibt dunkel, und unser Bürger kommt zum Schluss, dass eine von zwei Möglichkeiten eingetroffen sein müsse: ■ ■

Der Nachwächter hat das Kraftwerk angezündet. Ein Erdbeben hat die Überlandleitungen umgeworfen.

Leider kommt unser Bürger in Castrop-Rauxel nicht auf die Idee, dass ganz einfach die Glühbirne kaputt sein könnte. Es hätte ihm einiges erleichtert. Und leider kommen viel zu selten Windows-Admins und Netzwerk-Techniker auf die Idee, dass bei der Aussage »Das Netzwerk ist langsam« durchaus die Fehler auch mal vollständig beim Client-PC liegen könnten – oder an der logischen Umgebung, in der er sich bewegt. Natürlich hat jeder der werten Leser schon mehrfach mit seinem Analyzer nachgewiesen, welchen Unsinn der eine oder andere PC mal fertig bringt. Was hiermit gesagt werden soll, ist: ■ ■ ■

106

Fehler, die an einem einzelnen Server hängen, sind verhältnismäßig schnell und gut erkennbar. Fehler, die an einzelnen Netzwerk-Komponenten hängen (Switches, Router), sind ebenfalls in aller Regel schnell zuzuordnen bzw. behebbar. Fehler, die in einer komplexen Wechselwirkung stattfinden, unter anderem unter Mitwirkung des Client-PCs in dessen subjektiver Wahrnehmung davon, was er für die Wirklichkeit hält (für seine »Netzwerk-Umgebung«), sind schwer greifbar, weil weder die Arbeitsteilung der Analyse-Techniker, noch die Vorkenntnisse ihrer Ausbildung auf die Bewältigung solcher Szenarien ausgerichtet sind. >>> NEW TECH

Fehler in der Arbeitsteilung der Unternehmen

Das ist gar kein Vorwurf. Es ist die Feststellung, dass sich Arbeitsteilung und Arbeitsgewohnheiten über Jahre so entwickelt haben, wie sie sich entwickelt haben, und dass die resultierenden Strukturen nicht selten in dem bizarren Kreislauf stecken, ■ ■

dass sie die Fehler durch Mängel im organisatorischen Umfeld überhaupt erst entscheidend begünstigen, dass sie die Analyse bzw. Behebung der Fehler durch dieselben Mängel wiederum wirksam behindern bzw. gar verhindern (wovon der Verfasser mit seinem Beruf – und viele andere neben ihm – wiederum profitiert).

Es arbeiten also zu oft Menschen am Problem, die zwar für ihr eigenes Fach gut ausgebildet sind, aber für den aktuellen Fehler nicht über hinreichend Wissen und Erfahrung verfügen und falls das doch mal der Fall sein sollte, stellt sich das Wissen nicht selten als ungenügend heraus, denn: ■

■

Auf Grund bestimmten Wissens bzw. bestimmter Annahmen über die Wirklichkeit wurden in der Vergangenheit die Veränderungen (Konfigurationen, Migrationen) vorgenommen, die am Ende in einem Fehler, einem Crash endeten. Tritt nun ein Fehler bzw. Crash auf, wird auf Grund desselben Wissens bzw. auf Grund derselben Annahmen über die Wirklichkeit versucht, den Fehler zu finden.

Das klingt gefährlich nach der berühmten Katze, die sich in den Schwanz beißt und wenn man nun noch zusätzlich bedenkt, dass »die Annahmen über die Wirklichkeit« oft an derselben vorbeigehen, ergibt sich von selbst, dass eine LAN-Analyse oft nicht den gewünschten Erfolg hat. Denn nun kommen Fehler in der Arbeitsteilung der Unternehmen hinzu:

4.4 Fehler in der Arbeitsteilung der Unternehmen Viel zu oft ist zu beobachten, dass unerfreuliche Reibungsverluste zu den Fehlern führen, die dann mit den Mitteln der LAN-Analyse erkannt werden sollen: ■ ■ ■ ■

Abteilungen arbeiten viel zu sehr nebeneinander her, statt miteinander. Abteilungen tauschen viel zu selten Dokumentationen aus. Abteilungen verfügen noch nicht mal selber über die eigenen Dokumentationen – weswegen sie diese auch nicht austauschen können. Abteilungen streiten um ihre Budgets. Es ist für alle anderen Abteilungen aus Kostengründen günstig, mit der Analyse die Netzwerk-Abteilung zu beauftragen, denn es sind ja angeblich Netzwerk-Fehler, die da wirken.

Das ist nicht überall so, das ist nicht immer so, aber viel zu oft in viel zu vielen Unternehmen so.

>>> NEW TECH

107

Kapitel 4 • LAN-Analyse: Neue Wege

Nun muss das gar nicht darauf zurückzuführen sein, dass übel wollende Menschen mit schlechtem Charakter aufeinander losgelassen werden! Vielmehr führen in aller Regel ganz triviale Gründe zu solchen Verhältnissen: ■ ■ ■

Die Arbeitsüberlastung führt dazu, dass für Dokumentationen nicht mehr viel Raum und Zeit bleibt. Zu wenig Personal hat zu viele Aufgaben zu erledigen. Darunter leidet auch die Koordination zwischen den Abteilungen. Es fehlt an automatisierten Methoden, um allen gemeinsam die nötige Faktenbasis für eine gedeihliche Zusammenarbeit zur Verfügung zu stellen. Daher kennen die Netzwerk-Leute noch nicht einmal alle Server samt aller IP-Adressen; die Server-Leute kennen nicht alle Clients, die sich an ihren Servern einloggen; die Client-Leute kennen noch nicht einmal alle Configs, denen ihre Clients beim Login ausgeliefert sind.

Gehen wir's pragmatisch an und fragen uns: An welcher Stelle können wir etwas verändern – mit vertretbaren Mitteln, in hinreichend kurzer Zeit, mit ausreichender Wirkung? ■ ■ ■

Die Personalausstattung kann nicht kurzfristig geändert werden. Die Koordination zwischen den Abteilungen ist bei Personalknappheit auch behindert. Wenn es jedoch automatisierte Methoden zu einer sehr weit reichenden Informations- und Dokumentations-Beschaffung gäbe, könnte dies ein Ansatz sein, erhebliche Vorteile zu erreichen.

4.5 Automatisierte Methoden in Dokumentation und Analyse Zunächst einmal muss selbstverständlich festgestellt werden, dass es bereits reichliche Möglichkeiten gibt, durch automatisierte Methoden Unterstützung in Dokumentation und Analyse zu erlangen. Hierzu zählen vor allem die klassischen Mittel des Netzwerk-Managements: ■ ■ ■ ■ ■

SNMP Agent/SNMP Management Console RMON Agent/RMON Management Console Activity-Tools mit Ping, TraceRoute und dergleichen mehr Herstellereigene Frameworks, etwa Cisco Works Open Source-Software aus dem Linux-Lager, etwa NTOP

Diese Mittel jedoch müssen richtig eingeordnet werden, denn sie haben ihren eigenen, typischen Schwerpunkt: ■

108

Sie sind hauptsächlich statistisch ausgerichtet, also auf die Erfassung von Teilnehmeradressen (MAC-Adressen, IP-Adressen, TCP-Ports) und Mengenverhältnisse (wer mit wem wie viel?).

>>> NEW TECH

Automatisierte Methoden in Dokumentation und Analyse

■

Sie sind im Bereich der Analyse nur zu sehr einfachen Aussagen fähig. Umfangreiche Berichte über Fehler, Ereignisse und ungewollte Wechselwirkungen werden gar nicht oder kaum geliefert.

Es ist nicht ausgeschlossen, dass jetzt der eine oder andere Leser widerspricht. Es soll daher ergänzt werden: Unter »Analyse« werden hier Aussagen verstanden (bzw. Daten im Sinne von Dokumentation, Ablaufchronik oder Statistik), auch zu komplexen Wechselbeziehungen, zu unerwarteten Details von Dialogbeziehungen, zu völlig unvorhersehbarem Applikations-Verhalten. Um ein Beispiel zu geben: Allgemeiner Bestandteil sollte die vollständige Erfassung aller fehlgeschlagenen Versuche von Client-PCs sein, auf Server zuzugreifen und bestimmte Ressourcen zu nutzen bzw. anzufordern. Es ist nunmehr vermutlich konsensfähig, dass die allgemein bekannten Methoden der Netzwerk-Statistik, des Monitorings, des Managements solche Aussagen nicht liefern. Das ist auch nicht weiter verwunderlich, da die überwiegend meisten Werkzeuge online in Echtzeit arbeiten und daher nur begrenzt Zeit haben, vorbeilaufende LAN-Pakete zu untersuchen und in Tabellen zu verarbeiten. Wie auch immer: Um Qualitätskontrolle (vorbeugende Untersuchungen) und LAN-Analyse (Troubleshooting) effizient zu gestalten, müssen weit reichende Informationen praktisch allen Abteilungen des Unternehmens zur Verfügung gestellt werden (können). Das muss deutlich über die heute möglichen HTMLZugriffe auf die Statistik-Module von Switches und Servern hinausgehen. Der geneigte Leser dürfte schon ahnen, was der Verfasser im Blick hat: ■

■

Ständiges oder in gut geplanten Stichproben organisiertes Mitlesen und Speichern von LAN-Traffics über längere Zeiträume (halbe Tage, ganze Tage, Wochen) Automatisches Auswerten des gespeicherten LAN-Traffics mindestens über Zeitfenster, die typischerweise jeweils mindestens einen halben oder ganzen Tag abbilden

Um Produkte zu nennen, die das leisten können: ■

■ ■

Hochleistungs-Software wie EtherPeek NX (WildPackets) kann auf Gigabit-Ethernet bis zu 32 Gigabytes LAN-Traffic nonstop auf die Festplatte bringen (sofern der Messrechner entsprechend leistungsfähig ist). Spezialprodukte wie NetVCR (Niksun) sind in der Lage, hunderte von Gigabytes am LAN-Traffic permanent mitzulesen und zu speichern. Das vom Verfasser programmierte TraceMagic kann hunderte von Aufzeichnungs-Dateien der wichtigsten Analyzer-Formate nonstop automatisch verarbeiten und auch komplexe Fehlerbedingungen und Wechselwirkungen erkennen bzw. sichtbar machen.

Um jetzt noch den betrieblichen Nutzen erreichen zu können, muss die Verteilung der Ergebnisdaten sichergestellt werden.

>>> NEW TECH

109

Kapitel 4 • LAN-Analyse: Neue Wege

4.6 Verteilung der Ergebnisdaten nach erfolgter Analyse Wenn jeder Froschkönig auf der goldenen Kugel hocken bleibt, die in seinen Brunnen fällt, hat niemand etwas davon. Will sagen: Wer immer Daten hat, die für alle gemeinsam wichtig sind, soll sie auch allen zur Verfügung stellen. Dies geschieht heut weitgehend über HTML-Module, die vom System des Netzwerk-Managements inzwischen selbstverständlich geboten werden. Wie bereits in der Kritik der Analyzer ausgeführt, leiden die heutigen SoftwareAnalyzer unter anderem an dem Mangel, dass sie ihre Ergebnisse mehr oder weniger lediglich dem unmittelbaren Betrachter zur Verfügung stellen, der vor dem Bildschirm sitzt. Der eine Analyzer gibt schon mal CSV-Dateien aus, der andere HTML-Darstellungen, aber nicht wirklich wird ein automatisches Reporting unterstützt und die möglichst unkomplizierte Weitergabe von Ergebnisdaten an Dritte auch nicht. Nun kann aber Analyse kein akademischer Selbstzweck sein. Es kann auch nicht sein, dass der Eine dem Anderen erzählt, er hätte da mal auf dem Bildschirm, als der Analyzer lief, was Interessantes gesehen und das hätte nach diesem oder jenem ausgesehen. Die Glaubwürdigkeit und damit letztlich die Akzeptanz und die Umsetzungsfähigkeit von Ergebnisdaten hängt wesentlich von folgenden Faktoren ab: ■ ■ ■ ■ ■

Vollständigkeit (keine Stichproben, sondern Totalbefunde) Zuverlässigkeit/Unanfechtbarkeit Nachvollziehbarkeit/Transparenz Reproduzierbarkeit/Überprüfbarkeit Vermittelbarkeit/Verständlichkeit

Hier soll aber zunächst ein völlig einfacher Faktor herausgegriffen werden: die Fähigkeit, die Ergebnisdaten automatischer Analyse unkompliziert, schnell, umfassend an beliebige Dritte weitergeben zu können und das in einer Weise, die dem Empfänger die Möglichkeit gibt, schnellen Überblick zu erlangen, aber auch eigene Fragen an die Daten zu richten oder gezielte Weiterverarbeitung zu betreiben. Es ist schnell einsichtig, dass die heutigen Analyzer das nicht bieten. Sie sind One-Man-Shows bzw. erzwingen den Einzelkämpfer; sie unterstützen kaum Teamwork im Bereich der Analyse. Im besten Falle werden sogar umfassende Datenbanken, in denen AnalyseErgebnisse abgelegt und somit auch umfassend abfragbar sind, nach Belieben jedem Dritten zugänglich gemacht und jeder Empfänger kann in aller gewünschten Breite und Tiefe damit arbeiten. Entsprechend müsste es im Bereich der automatischen Analyse zwei Module geben: ■ ■

110

Analyse-Modul (müssen nur wenige bedienen) Reporting-Modul (muss beliebig vielen zugänglich sein)

>>> NEW TECH

Betriebliche Abläufe und ihre Forderungen an die Analyse

Wenn wir über Datenbanken als Träger von Ergebnisinhalten sprechen, wird schnell deutlich, dass HTML-Lösungen nur begrenzt angemessen sein können. Es kann also auch gefordert sein, jedem Empfänger einer automatischen Auswertung die komplette Datenbank einer Auswertung zur Verfügung zu stellen – mit einer Software, die in der Lage ist, diese Daten zu lesen und sogar weiterzuverarbeiten. Und diese Betrachter-Software dürfte im Idealfall nichts oder nur wenig kosten, um die Verbreitung bzw. die Weitergabe der Daten nicht unnütz zu behindern. Nichts anderes als dieses Konzept verfolgt TraceMagic mit seinen zwei Modulen: ■ ■

TraceMagic Capture File ANALYSIS TraceMagic Report VIEWER

Bei TraceMagic ist das Analyse-Modul zu lizenzieren (kostet also Geld), während das Viewer-Modul lizenzfrei ist und somit völlig frei verbreitet werden kann. Der Verfasser rechnet damit, dass dieses Beispiel über kurz oder lang Schule machen wird – denn bei näherer Betrachtung der betrieblichen Abläufe kann es eigentlich gar nicht anders sein.

4.7 Betriebliche Abläufe und ihre Forderungen an die Analyse Man stelle sich die Situation vor: Es treten unvorhergesehene Fehler auf, an denen allem Anschein nach mehrere Server, mehrere Clients, womöglich sogar verschiedene Switches beteiligt sind. Niemand weiß etwas Genaues. Der Fall ist kompliziert. Der Hersteller der Switches hat nicht gerne, dass der Fall an ihm hängen bleibt, verschließt sich aber auch nicht konstruktiven Hinweisen; der Lieferant der Server-Applikation zeigt eine ähnliche Einstellung (vorsichtig und zurückhaltend, aber durchaus aufgeschlossen) und die hausinternen Abteilungen stehen unter Druck, wollen sich aber auch gegenseitig sowie gegenüber der Chefetage keine Blöße geben und die Chefetage steht auch unter Druck und hat von Technik keine Ahnung. Das ist der Stoff, aus dem die aufregenderen Geschichten dieses Berufs gestrickt werden. Was nun? Üblicherweise schickt jetzt jeder seinen eigenen Techniker an die Front. Alle sollen zusammenarbeiten, tun sie auch, aber am Ende muss damit gerechnet werden, dass sich alle auf die Ausgangsposition zurückziehen, um dem Selbstschutz genüge zu tun und den Standpunkt zu vertreten, man habe damit nichts zu tun oder man könne wenigstens nichts Genaues sagen.

>>> NEW TECH

111

Kapitel 4 • LAN-Analyse: Neue Wege

Der eine oder andere hängt sich mit dem Analyzer an die Leitung. Dieser oder jener aus dem Gesamtgefüge zweifelt hier und da die Ergebnisse an, die mit dem LAN-Analyzer (angeblich) erarbeitet wurden, schon allein deswegen, weil die manuelle Durchsicht der Messdaten nur kleine Zeitfenster als Stichproben zur Auswertung geraten ließ. Die einen sind von diesem überzeugt, die anderen von jenem. So gehen dann Tage ins Land. Aber selbst angenommen, wenn sich die meisten auf eine gemeinsame Auffassung einigen, stellt sich oft heraus, dass sie nicht entscheidungsbefugt sind. Womöglich müssen nun die Befunde an die Zentrale des einen oder anderen Herstellers geschickt werden und dort muss sich nun jemand mit hohem Aufwand wieder in alles hineindenken und die Frage, ob das eigene Haus (als Hersteller bzw. Lieferant) haftungsrechtlich herangezogen werden kann, hängt an der Frage, ob verschiedene Befunde wirklich »wasserdicht« sind. Das ist eine unangenehme Lage. Aus betrieblicher Sicht sollte das Ganze doch deutlich anders ablaufen: schneller, zuverlässiger, kommunikativer, effizienter. Hier könnte sich nunmehr der Nutzen einer automatischen, analytischen Untersuchung großer Mengen von Messdaten erweisen: ■

■

■

■

Die Analyse großer Datenmengen (bzw. langer Zeitfenster, in der Regel ganzer Tage) läuft voll automatisch und belastet keine Arbeitskraft; außerdem ist sie »neutral«, sie wird nicht von der einen Partei durchgeführt und von der anderen sofort angezweifelt. Sie beschränkt sich zudem nicht auf Stichproben, sondern liefert Totalbefunde, die eben genau deswegen glaubwürdig sind. Die Fähigkeit eines solchen Verfahrens, neben dem Nachweis der Fehleranwesenheit (»Positiv-Befund«) auch den zuverlässigen Nachweis der Fehlerabwesenheit (»Negativ-Befund«) zu erbringen, beschleunigt den Meinungsaustausch in angenehmer Weise: Es kann schnell die Konzentration auf das Wesentliche erfolgen; alle anderen Varianten scheiden aus. Die Möglichkeit, die Ergebnisse in Gänze an alle Beteiligten weiterzugeben samt des nötigen Betrachter-Moduls (»Viewer«), versetzt alle gemeinsam in die Lage, Überblick zu gewinnen, Zuordnungen zu treffen, gezielte Abfragen an die Ergebnis-Datenbank zu richten. Die Möglichkeit, automatisch erzeugte Reports unkompliziert mit eigenen bzw. zusätzlichen Kommentaren zu versehen, versetzt alle Beteiligten in die Lage, sich schnell und umfassend auszutauschen. So ist die Wahrscheinlichkeit größer, dass Befunde gemeinsam erarbeitet und am Ende auch von allen anerkannt werden.

Ein Verfahren, das mit diesen Mitteln arbeitet, ist wesentlich effizienter als das, was in den letzten zehn Jahren betrieben wurde. Es führt daher zu wesentlich schnelleren Reaktionszeiten und es vermindert die Kosten für das Unternehmen:

112

>>> NEW TECH

Dauerhafte Qualitätssicherung über automatische Analyse-Verfahren

■ ■ ■

Kosten durch Personalbindung im eigenen Hause im Zuge der Analyse Kosten für Externe, die eigens im Störfall angeheuert werden Betriebsausfallkosten im Zusammenhang mit einer Störung

Das führt natürlich sofort zu der Frage: Warum soll man ein solches Verfahren nur re-aktiv bzw. nach einem Störfall verwenden? Warum soll man nicht eine ständige Qualitätssicherung durchführen? Warum also sollte man nicht proaktiv Analyse betreiben, Vorsorge-Untersuchungen wie beim Zahnarzt? Dieser Ansatz ist berechtigt und weist den Weg in die Zukunft.

4.8 Dauerhafte Qualitätssicherung über automatische Analyse-Verfahren Die Verfügbarkeitsanforderungen an Daten und Dienste stehen allgemein knapp an der 100-Prozent-Marke. Die Unternehmen können sich im Grunde gar nicht leisten, dass Analyse nur im Ernstfall betrieben wird, wenn es schon zu spät ist. In vielen Unternehmen aber ist die Personaldecke viel zu knapp, um wirklich vorbeugend Analyse betreiben zu können. Denn die heutigen LAN-Analyzer verlangen einen viel zu hohen Zeiteinsatz des Personals, da die Durchsicht der LAN-Pakete nur höchst eingeschränkt durch die so genannten Expertensysteme der Analyzer automatisiert wird (es kann immer nur eine Trace-Datei zur selben Zeit verarbeitet werden). Vermutlich würden viele Unternehmungen schnell und schlicht entscheiden: »Wenn es automatisierte Verfahren zur Fehler-Analyse gäbe, etwa so wie die automatischen Verfahren des Netzwerk-Managements, so hätten wir sie längst im Einsatz.« Diese Aussage dürfte wohl doppelt richtig sein: Wenn es sie in der Vergangenheit gegeben hätte, wären sie bereits im Einsatz, nur leider gab es sie bisher nicht. Wie nun könnte ein System der dauerhaften Qualitätssicherung aussehen? ■

■

Entweder werden an den zentralen Punkten des Backbones alle Daten mitgelesen und gespeichert (Beispiel: NetVCR, Niksun) oder es wird punktuell in einem intervallartigen Reihum-Prinzip mit Stichproben gearbeitet (z.B. mit EtherPeek NX von WildPackets). Das Prinzip von Reihum-Stichproben arbeitet wie folgt: Es werden im Unternehmen Messpunkte definiert, die repräsentativ sind und die Hauptdatenströme abbilden. Angenommen, es gäbe sechs solcher Messpunkte, so würde in jeder Woche einer dieser Messpunkte für einen ganzen Tag abgegriffen: Jede Woche würde für 24 Stunden der gesamte Traffic eines Messpunkts mitgelesen und gespeichert, sagen wir: immer von Dienstag früh, 07:00 Uhr bis Mittwoch früh, 07:00 Uhr.

>>> NEW TECH

113

Kapitel 4 • LAN-Analyse: Neue Wege

■

Die Messdaten dieser 24-Stunden-Proben werden automatisch ausgewertet; die Ergebnisdaten werden allen Abteilungen des Unternehmens (sowie ggf. Lieferanten und externen Dienstleistern) zur Verfügung gestellt.

■

Jeder Empfänger hat ein »Viewer«-Modul auf seinem Rechner, mit dem die Ergebnisdaten betrachtet, abgefragt und weiterbearbeitet werden können. Jeder Empfänger ist aufgefordert, binnen fest vereinbarter Fristen (sagen wir drei Tagen) Antwort zu geben auf die Befunde. Berichts- und Antwortpflichten gehören zu jedem unternehmenskritischen Kontrollprozess.

■

■

Nach sechs Wochen sind alle vorher bestimmten Messpunkte durchlaufen. Um Urlaubszeiten und Krankheitstage mit zu berücksichtigen, wird der gesamte Messzyklus mit sechs Messpunkten auf acht Wochen festgelegt. Das sind zwei Monate. Somit kann der gesamte Zyklus zuverlässig sechsmal jährlich durchlaufen werden.

■

Die Wahrscheinlichkeit, dass sich noch Fehler unbemerkt nach und nach im Hintergrund aufbauen können, ist nunmehr nahe Null. Ein automatisches Analyse-Verfahren, das 24-Stunden-Messungen bis zum Totalbefund verarbeiten kann, zeigt das erste Auftreten von Fehlern bereits, wenn diese noch in homöopathischen Mengen auftreten.

■

Mit diesem zuverlässigen System gesicherter Erkenntnis kann das Unternehmen von re-aktiven Regelkreisläufen zu pro-aktiven Arbeitsteilungen übergehen.

■

Die Fähigkeit zum Troubleshooting im Ernstfall wird nicht etwa geschmälert, sondern verbessert, weil die permanente Qualitätssicherung einerseits die dokumentarische Basis dramatisch verbessert, andererseits das Systemverständnis aller Beteiligten über die Monate und Jahre wachsen lässt.

Dieses System hat den großen Vorteil, auch über verschiedene Standorte sogar landesweit oder weltweit möglich zu sein. Wie das? ■

Messdaten müssen nicht von teuren System-Technikern der Zentrale von der Leitung abgegriffen werden. Das Drücken von START/STOPP-Buttons kann auch von gutwilligen Buchhaltern oder begabten Heizungstechnikern vorgenommen werden (um es mal übertrieben auszudrücken).

■

Die Messdaten aus Niederlassungen werden auf CD-ROM gebrannt und an die Zentrale geschickt. Dort findet die automatische Auswertung statt, von dort werden die Ergebnisse per E-Mail oder CD-ROM zurückgegeben an die Niederlassung sowie per Verteiler an alle anderen Empfänger weitergereicht.

Dieses Verfahren ist möglich, reichlich unkompliziert und darüber hinaus immens effizient.

114

>>> NEW TECH

Die Revisionsfähigkeit der Netzwerke

4.9 Die Revisionsfähigkeit der Netzwerke In (fast) allen Bereichen eines Unternehmens (zumindest bei größeren Betrieben) sorgt die Revisionsabteilung für die Einhaltung der gesetzlichen und betriebs-internen Vorschriften. Für Revisoren gibt es verschiedene Gründe, über Zustände unglücklich zu sein: ■ ■ ■

Es gibt Vorschriften, aber sie werden nicht eingehalten. Es gibt Vorschriften, sie werden wohl auch eingehalten, aber es lässt sich nicht nachweisen. Es gibt gar keine Vorschriften, also hält sie auch keiner ein.

Es ist leicht ersichtlich, dass im Bereich von Datenverarbeitung und Datenkommunikation ... ■ ■ ■

entweder keine Vorschriften existieren (weil sowieso davon ausgegangen wurde, dass sie nicht überprüfbar sind) oder es gibt sie, aber sie werden nicht überprüft (weil die Mittel dazu fehlen) oder es gibt sie, sie werden auch überprüft, aber niemand versteht die Ergebnisse.

Das alles kann doch nicht im Ernst gewollt gewesen sein? Um die Revisionsfähigkeit der Datenkommunikation herzustellen (bzw. die Revisionsfähigkeit der Applikations-Vorgänge, die sich in der Datenkommunikation abbilden und durch sie nachweisen lassen), müssen folgende Mindestbedingungen erfüllt sein: ■

■ ■

Ein automatisches Verfahren muss ein festes Spektrum von Kriterien abarbeiten. Dieses Spektrum muss mindestens bekannt sein, im besten Fall ist es definierbar bzw. erweiterbar. Die Ergebnisse müssen umfassend, zuverlässig, unanfechtbar, verifizierbar und reproduzierbar sein. Nicht nur Positiv-Befund (Nachweis der Anwesenheit von Fehlern), sondern auch der Negativ-Befund (Nachweis der Abwesenheit von Fehlern) müssen in vollem Umfang über das Prüfspektrum möglich sein. (Sonst wäre die Revisionsfähigkeit nicht gegeben.)

Alles ist mit den oben beschriebenen Verfahrensweisen ganz oder weitgehend machbar. Somit können Unternehmen die dauerhafte Qualitätssicherung der Datenkommunikation (bzw. der Prozesse, die über Kommunikation miteinander austauschen) nicht nur tatsächlich gewährleisten, sondern sie können sogar die Schwelle zur Revisionsfähigkeit überschreiten. Somit werden auch ganz alltägliche Vorgänge wieder interessant: ■ ■

Abnahmeprotokolle Leistungsnachweise

>>> NEW TECH

115

Kapitel 4 • LAN-Analyse: Neue Wege

■ ■

Erfolgskontrolle bei Migration etc. Qualifizierte Rüstscheine und To-do-Listen

Wenn alles dies mit den Mitteln eines automatischen Berichtswesens erfolgt, das LAN-Analyse auf hohem Niveau umsetzt, so werden betriebliche Abläufe nicht nur vereinfacht und beschleunigt, sondern insgesamt revisionsfähig und somit aus der Sicht der Unternehmensleitung planbar und in den Kosten berechenbar.

4.10 Planbarkeit und Kostenrechnung Planbarkeit und Kostenrechnung gehören zu den zentralen Bestandteilen jeglicher Unternehmensführung. Die EDV sowie die LAN-WAN-Kommunikation galten lange als Schwarze Löcher, die Geld anziehen, es aber nicht wieder hergeben. Vor allem das unkontrollierte, stete Nachfordern von Finanzmitteln hat bei vielen Unternehmen keine rechte Freude aufkommen lassen. Eine dauerhafte, pro-aktive Qualitätssicherung mit den Mitteln von LAN-Analyse auf hohem technischen Niveau kann erheblich dazu beitragen, hier eine Kehrtwende zu erreichen. Dies mag an dieser Stelle weit hergeholt erscheinen. In den weiteren Kapiteln dieses Buches wird deutlich werden, was automatische Analyse zu leisten vermag – und welche immensen Einwirkungen genaue Befunde auf die Ablauf- und Finanzplanungen eines Unternehmens haben können. Die Kosten für die nötige Analyse- und Auswertungs-Technik ist oft nach nur einem Jahr wieder eingespart, weil nicht mehr ziellos nach dem Gießkannenprinzip investiert wird (nach dem Motto »viel hilft viel«), sondern weil auf Grund klarer, genauer Befunde zielgenau angeschafft und beauftragt wird. Spätestens bei den Themen »Kosten« und »Einsparungen« dürfte das Interesse auch für zunächst abwegig erscheinende Lösungen geweckt sein.

116

>>> NEW TECH

Kapitel 5 TraceMagic Dieses Kapitel soll das Werkzeug vorstellen, auf dessen Arbeit die meisten der vorgestellten Befunde beruhen. Sie finden TraceMagic (www.tracemagic.net) auf der beiliegenden CD-ROM. Wenn Sie den Installationsanweisungen folgen, erhalten Sie eine funktionsfähige TraceMagic-Version, die jedoch mit der Einschränkung versehen ist, nur eine begrenzte Menge von LAN-Paketen auswerten zu können: Ohne Lizenzierung können nur jeweils die ersten 10.000 Pakete einer jeden Trace-Datei ausgewertet werden. Um den vollen Funktionsumfang zu nutzen bzw. zu testen, reicht das völlig aus. Sogar passable Diagnostik ist selbst bei dieser Mengenbeschränkung möglich. Ansonsten soll dieses Kapitel hauptsächlich erreichen, dass Sie die später im Buch vorgestellten Fehlerbefunde hinsichtlich der Methode verstehen, mit der sie erhoben wurden. Insofern TraceMagic eine deutlich veränderte Arbeitsweise hat (verglichen mit herkömmlichen Analyzern), muss die Methodik geläufig sein, um die Befunde verifizieren zu können. Das alles ist nicht sonderlich schwierig und soll daher zügig dargestellt werden.

5.1 Historische Entwicklung Der Verfasser betreibt mit seinem Unternehmen Synapse:Networks LAN-Analyse seit 1992. Damals war es der LANdecoder von Triticom, der die Neugierde, dann aber auch die Begeisterung für dieses Thema weckte. Bald war LAN-Analyse das hauptsächliche Ertragsfeld des Unternehmens geworden und folglich hing alles davon ab, dass die richtigen Werkzeuge für die Fehlerdiagnose vorhanden waren. Als Erstes wurden Protokoll-Dokumentationen gesucht und nur unzureichend gefunden, die Folge war der Aufbau einer eigenen Datenbank (BANalyzer), die zunächst über CompuServe weltweit verteilt wurde. Heute sind die Protokollbeschreibungen im HTML-Format im Internet freigegeben (www.banalyzer.com). Die kompletten Protokolldarstellungen in HTML sowie im Windows-Hilfeformat sind zudem auf CD-ROM erhältlich. Als das Mitte der 90-er Jahre vollbracht und das Wissen gut vermehrt war, stellte sich heraus, dass die Fragen, die sich ergaben, nicht mehr mit den Mitteln der vorhandenen LAN-Analyzer zu beantworten waren.

>>> NEW TECH

117

Kapitel 5 • TraceMagic

Im Besonderen die Einschränkung aller Analyzer, jeweils nur eine einzige TraceDatei zur selben Zeit offline untersuchen zu können, führte schnell zu der Erkenntnis: Spätestens in der Zeit von 100 Megabit oder sogar Gigabit würde eine solche Architektur den Erfolg des Diagnosehandwerks gefährlich in Frage stellen – und damit die Ertragsgrundlage eines jeden LAN-Analysten. So kramte der Verfasser im Jahre 1996 sein altes Turbo Pascal 6 wieder hervor und begann mit dem Programmieren. Schon 1997 war die unter DOS laufende Auswertungs-Software LANreport fertig. Sie konnte mehrere hundert TraceDateien automatisch hintereinander verarbeiten, Ergebnistabellen ausgeben (.CSV), chronologische Ereignis-Logs erzeugen und sogar mit Filtern arbeiten. In 1997 schickte der Verfasser das Programm an Triticom (den Hersteller von LANdecoder32), um zu zeigen: »Seht her, so geht das und bitte programmiert das doch bitte unter Windows neu und integriert es in Eure Analyzer-Suite!« Denn der Verfasser war der Meinung, dass er LAN-Analyst wäre und kein Programmierer. Warum sollte er das tun, was andere besser können? Es gab zwar Antwort und einige der LANreport-Ideen fanden sich später hier und da wieder. Aber im Kern wurde das Konzept nicht übernommen. So kam 1997 keine Antwort, auch in 1998 wurde vergebens gewartet und bis zum Sommer 1999 kam – nichts. Daraufhin entschied sich der Verfasser, nun doch selber zur Nothilfe zu greifen und LANreport auf Windows zu portieren, um in der aufziehenden GigabitZeit weiter handlungsfähig zu bleiben. Da ab Ende 1999 die Arbeiten zum ersten Buch begannen (Networker’s Guide, April 2000) und da dieses Buch dazu führte, dass zunächst eine Datenbank über die Windows-Registry zu programmieren war (RegCheck) und dass später aus diesem Anlass ein zweites Buch zu schreiben war (Registry Guide, April 2001), verzögerten sich die Arbeiten der Portierung bis Ende 2000. Dann aber wurde nonstop an dem Projekt gearbeitet und das Ergebnis liegt nunmehr vor in Form des LANreport-Nachfolgers namens TraceMagic.

5.2 TraceMagic ist anders Der Bedarf für ein neues Expertensystem der LAN-Analyse ergibt sich aus den gravierenden Mängeln der bisher verfügbaren Produkte. Eine Abgrenzung ist daher notwendig bzw. ergibt sich aus der Sache.

5.2.1

Gängige LAN-Analyzer und ihre Entwicklungs-Systematik

Bis heute hat sich kein zweiter Hersteller gefunden, der eine solche AnalyseSoftware bzw. ein solches Expertensystem entwickelt hätte. Das ist auch nicht verwunderlich. Es spricht sogar einiges dafür, dass dieser Zustand anhalten kann.

118

>>> NEW TECH

TraceMagic ist anders

Die bekannten Hersteller können gar nicht anders, als bestehende Protokollvorschriften (etwa veröffentlicht in den bekannten RFCs) Zug um Zug zu implementieren. Kommen neue Protokolle auf, müssen sie eingearbeitet werden. Das alles kostet sehr viel Zeit, verlangt einen immensen Aufwand in der Qualitätskontrolle und geht weitgehend von der Theorie der Standardisierungs-Vorschriften aus, nicht von der realen Praxis der Fehlersuche. Die Programmierer sind Programmierer, keine Praktiker der LAN-Analyse. Ihnen fehlt jegliche Erfahrung, wie man sich methodisch-handwerklich in einer komplexen IT-Umgebung einem Fehler nähert, der in mehrfachen Wechselwirkungen zwischen verschiedensten Netzwerk-Komponenten auftritt. Sie haben keine Vorstellung davon, welche bizarren Fehler jenseits aller RFC-Normierungen tatsächlich in der Welt »da draußen« die Netze belasten. Viele der Programmierer verschiedenster Hersteller, einschließlich einiger ChefEntwickler und Eigentümer, haben dem Verfasser dies persönlich dargelegt. Es bleibt also nicht aus, dass die gängigen Analyzer aus akademischer Sicht nach lexikalischer Vollständigkeit ihrer Protokollbibliotheken streben – und dass sie daher eine gewissen Praxisferne nie überwinden können.

5.2.2

TraceMagic und dessen Ansatz »von hinten herum«

TraceMagic wird dagegen völlig anders entwickelt. Selbstverständlich liest der Verfasser dieser Zeilen gleichfalls RFCs und implementiert ihre Protokollvorschriften (sofern nötig). Bei TraceMagic ist das jedoch nur eine Hilfsfunktion, denn tatsächlich wird dieses Expertensystem »von hinten herum«, also vom gewünschten Ergebnis her, entwickelt. Das heißt: Der Verfasser verdient immer noch sein Geld mit Analyse-Dienstleistungen. Da er auf die schwierigen und scheinbar aussichtslosen Fälle spezialisiert ist, ist er weiterhin immer wieder gezwungen, viel Handarbeit zu leisten und komplexe Fehler-Szenarien manuell zu isolieren. Ist am Ende eine neue Erkenntnis über bestimmte Fehlerabläufe, Fehlerursachen und Wechselwirkungen gewonnen, wird die Frage gestellt: Wie kann die Diagnose automatisiert werden? Sodann werden genau die Entwicklungsschritte im Programm-Code vorgenommen, die nötig sind, um den Fehlerbefund automatisch erbringen zu können (sowohl in Positiv- wie in Negativ-Befund). Das führt dazu, dass nicht in jedem Fall für jedes Protokoll jede kleine Nebenvorschrift implementiert wird. Was in der Praxis überhaupt keine Fehler hervorbringt (oder nicht seinerseits auf Fehler nervös reagiert), ist unerheblich und kann daher ausgelassen werden. Diese Beschränkung auf das Wesentliche hat dazu geführt, dass – welch vermeintlicher Widerspruch! – TraceMagic heute allen anderen LAN-Analyzern in weiten Bereichen der Fehlerdiagnose haushoch überlegen ist.

>>> NEW TECH

119

Kapitel 5 • TraceMagic

Da die Entwicklerzeit ausschließlich auf die folgenden Punkte konzentriert ist, ist das Entwicklertempo so hoch, dass eine quälend langsame RFC-Umsetzung (wie sie von anderen Herstellern zwangsweise zu verfolgen ist) gar nicht mithalten kann. Auf die folgenden Punkte wird das Hauptaugenmerk gerichtet: ■ ■ ■ ■ ■ ■ ■ ■

Möglichst umfassende Überwindung der Datei-Grenzen, wenn hunderte von Trace-Files automatisch verarbeitet werden Erkennung von möglichst vielen Fehlern und Vorgängen Erkennung von Ursachen und Wechselwirkungen Dokumentation aktiver Netzwerk-Komponenten und Verhaltensweisen Verdichtete Ergebnisausgabe in Tabellen und Listen Lesbare Ergebnisausgabe u.a. in chronologischen Ereignis-Logs Verarbeitungsfähige Ergebnisausgabe in Form umfassender Datenbanken Vermittlungsfähigkeit der Ergebnisse durch übersichtliche, lesbare Formate

Das Ganze ist auf Ergebnis orientiert, nicht auf die akademisch-lexikalische Vollständigkeit: Exotische und völlig wirklichkeitsferne Protokollvarianten werden in aller Regel ausgelassen, um die Zeit und die Ressourcen für wirklich wichtige Funktionen frei zu haben.

5.2.3

»Beschränkung aufs Wesentliche« versus »Perfektion total«

Das Vorhaben, mit TraceMagic den wesentlichen Fehlern und Ereignisabläufen zu folgen, war und ist richtig. Der Erfolg bestätigt jeden Tag erneut die Richtigkeit und die vielen Kunden, die bei Synapse:Networks einkaufen, bestätigen den Erfolg immer wieder neu (siehe unten). Das Verblüffende nämlich ist: Das Prinzip, sich auf das Wesentliche zu beschränken, hat zu Fehlererkennungs-Bibliotheken geführt, die bei weitem alles übersteigen, was die Welt bei den bisher gängigen Analyzern gesehen hat. Das entscheidende und am besten greifbare Beispiel liefert die TCP/IP-Analyse: Herkömmliche Analyzer arbeiten mit etwa 10–30 Ereignis- und Fehlerzählern. TraceMagic dagegen arbeitet mit weit über 200 solcher Zähler und das sowohl netzwerkweit (over-all) als auch bezogen auf einzelne IP-Hosts, wobei TraceMagic bis zu 65.500 IP-Teilnehmer mit diesen rund 200 Zählern charakterisieren kann. (Einige dieser Zähler arbeiten im Hintergrund und werden nach außen nicht sichtbar.) Das führt zu wichtigen Feststellungen: ■ ■

120

Das Prinzip, sich auf das Wesentliche zu beschränken, hat zu gigantisch größeren Bibliotheken geführt, als sie die üblichen Analyzer bieten. Daraus folgt, dass der auf Ergebnisse orientierte Entwicklungsansatz am Ende wesentlich weiter führt als das sture Abschreiben von RFCs.

>>> NEW TECH

TraceMagic ist anders

■

Das ist wiederum leicht erklärlich, denn in den RFCs gibt es für eine Vielzahl der heute gängigen LAN-WAN-Fehler überhaupt keine Hinweise. Wie auch! Die Abweichungen sind nicht wirklich Gegenstand der Standardisierungs-Vorschriften (von Ausnahmen, die es tatsächlich gibt, abgesehen).

Noch im Frühjahr 2002 fragte einer der US-Weltmarktführer (Hardware- und Software-Analyzer) beim Verfasser an, ob er bereit wäre, Funktionen aus TraceMagic auszukoppeln und der Analyzer-Suite dieses Herstellers zur Verfügung zu stellen. Das Gespräch führte am Ende zum Abbruch – unter anderem deswegen, weil die Analyse-Methoden und Fehlerbibliotheken der Vorstellungswelt dieses Herstellers so fremd waren, dass schon der Versuch scheiterte, das alles via E-Mail zu erklären. Als der Verfasser sich die Freiheit nahm, die TCP/IP-Analyse dieses Herstellers schlicht für »lächerlich« zu halten, wurde der Gesprächspartner verschnupft und meinte, doch mal auf die Qualitäts-Software aus eigenem Hause hinweisen zu müssen. Da blieb nichts anderes übrig, als darauf hinzuweisen, dass die angeblich so gute US-Software für die Protokolle IP-ICMP-UDP-TCP gerade mal 11 (!!) Fehler- und Ereigniszähler führte ... und TraceMagic weit über 200. Der weitere Verweis, dass im Internet eine CSV- bzw. XLS-Datei zum Download liegt (seit Dezember 2001), in der das Kommunikationsverhalten von 22.661 IP-Hosts in besagten rund 200 Zählern abgebildet ist, führte dann zur finalen Sprachlosigkeit auf der anderen Seite des Ozeans: http://www.synapse.de/tracemagic/tm.power.htm

Diese kleine Episode, die Grund genug zum Schmunzeln gibt (wie aber auch zum Kopfschütteln), zeigt, dass der Ansatz, sich aufs Wesentliche zu beschränken, in völliger Verkehrung der guten Vorsätze mit TraceMagic das inzwischen größte, umfassendste und effizienteste Werkzeug im Bereich der TCP/IP-Analyse hervorgebracht hat. Das Ganze hat sich übrigens inzwischen im Bereich von Name Services, File Services und Application Layer ähnlich entwickelt.

5.2.4

TraceMagic in der Praxis und was Kunden sagen

Der veränderte Ansatz zur LAN-Analyse, den TraceMagic verfolgt, hat in Deutschland Kunden gefunden, die mit großen Datenvolumina und/oder mit hohen Verfügbarkeitsanforderungen zu tun haben. Dazu gehört inzwischen die Bundesregierung (BMVg = Bundesverteidigungsministerium), ein maßgeblicher Rüstungskonzern, WAN-Provider, mehrere Unternehmen der Rundfunk- und Fernsehtechnik, Industrie-Unternehmen, EDVDienstleister.

>>> NEW TECH

121

Kapitel 5 • TraceMagic

Ein Kunde, der sich »geoutet« hat, ist der Bayerische Rundfunk, der seine unternehmensweite LAN-Analyse inzwischen erheblich auf zentrale Auswertungen mit TraceMagic stützt, wobei verteilte Capture Engines (TcpDump, Ethereal, NTop) an verschiedenen, fest definierten Messpunkten im ReihumPrinzip tageweise LAN-Traffics einsammeln. Ein Anwenderbericht über diese Form der LAN-Analyse beim Bayerischen Rundfunk ist erschienen am Freitag, dem 11. Oktober 2002, in Heft 19/2002 des Magazins Network World/Germany: Netzwerkmanagement und LAN-Analyse beim Bayerischen Rundfunk Artikel: http://www.networkworld.de/index.cfm?pageid=104&id=89291&type=detail

Interview: http://www.networkworld.de/index.cfm?pageid=104&id=89259&type=detail

Das Prinzip, an wichtigen Punkten turnusmäßig tageweise Messdaten aufzuzeichnen und diese sodann zentral über TraceMagic auszuwerten, ist beispielhaft dargelegt und gut nachvollziehbar.

5.3 Das Konzept von TraceMagic Folgende Merkmale kennzeichnen wesentlich die Funktionsweise von TraceMagic: ■ ■

TraceMagic verfügt selber über keine Capture Engine, kann also selber keine Messdaten von der Leitung holen. TraceMagic unterstützt die wichtigsten bzw. gängigsten Analyzer-Formate, was deren Aufzeichnungs-Dateien (Capture Files, Trace Files) anbetrifft, wobei jeweils folgende Topologien unterstützt werden (sofern vom Analyzer gegeben): Ethernet, Token-Ring, FDDI. Hier ist die Liste der erkannten Analyzer-Formate (in alphabetischer Reihenfolge): – Anasil (LFNetworks) (.cap) – Ethereal (Ethereal) (.dmp) (Format von TcpDump) – EtherPeek, TokenPeek (WildPackets) (.pkt, .tpc) – LANdecoder32 (Triticom) (.enf, .trf) – Observer (Network Instruments) (.bfr) – Sniffer / DOS (.enc, .trc, .fdc) – SnifferPro / NetXRay (.cap) – Surveyor (Shomiti-Finisar) (.cap)

122

>>> NEW TECH

Das Konzept von TraceMagic

– TcpDump (TcpDump) (.dmp) – Die verschiedenen .CAP-Dateien sind in unterschiedlichen Formaten abgespeichert und sofern nicht identisch. ■

■

■

■

■

Der erste Zweck von TraceMagic ist, mit seinem Expertensystem mehr als jeweils nur eine Trace-Datei verarbeiten zu können. Die Entwicklung des Programm-Codes achtet sehr darauf, dass die Datei-Grenzen so weit wie möglich unerheblich bzw. überwunden werden. Das setzt übrigens eine entsprechende Ausstattung des Rechners hinsichtlich der Kapazitäten bzgl. RAM und Festplattenplatz voraus. Der zweite Zweck ist die vollautomatische Berichtsausgabe. Der bisher übliche Aufwand an Personal und Zeit in der Analyse (bzw. in der Durcharbeitung vieler Trace-Dateien) soll so weit wie möglich entfallen. Dieses Ziel ist weitgehend erreicht. Der dritte Zweck ist die Orientierung auf Ergebnisse, also Fehlernachweise. Statistiken, die nichts aussagen, werden entweder vermieden oder ergänzt um weitere Tabellen, Reports und Logs, welche neben den quantitativen Auswertungen auch qualitative Aussagen liefern. Der vierte Zweck ist die bestmögliche Vermittelbarkeit der Ergebnisse an Dritte. Analyse soll kein Selbstzweck sein, sondern möglichst direkt auf Umsetzung angelegt sein. Hierzu ist zwingend erforderlich, dass alle Beteiligte in einer IT-Umgebung (Fachabteilungen, Lieferanten, Externe) das komplette Ergebnismaterial einer Analyse in geeigneten Formaten vorgelegt bekommen. Daraus folgt, dass TraceMagic die Ergebnisse lesbar im Format von .TXT-Dateien ausgibt, für Excel (o.Ä.) im .CSV-Format, für umfangreiche Recherchen als Datenbank im .DB-Format (Paradox-Tabellen, verwaltet über die Borland Database Engine). Es soll zu einem möglichst geschlossenen Informationskreislauf kommen. Im besten Falle gibt eine Abteilung oder eine ferne Niederlassung in festen Intervallen Messdaten an die Zentrale, wo sie auf einer schnellen Maschine ausgewertet werden – mit dem Ende, dass die Ergebnisdaten (Reports) an alle Beteiligten weitergeleitet werden, darunter natürlich die Verantwortlichen besagter Abteilungen und Niederlassungen.

Dieser Kreislauf wird über folgendes Diagramm dargestellt: Dabei ist gut zu sehen: Die Messdaten werden mit (fast) beliebigen Analyzern in den LANs von der Leitung gezogen; bei fernen Niederlassungen werden diese Messdaten auf CD-ROM an die Zentrale geschickt. Dort werden sie der automatischen Analyse unterzogen. Die dabei erzeugten Reports und Datenbanken werden wiederum verteilt (je nach Umfang per E-Mail oder per CD-ROM) und über das »Viewer«-Modul können beliebige Dritte ohne Einschränkung insbesondere die Datenbank-Funktionalität benutzen, um die Auswertungsergebnisse zu nutzen.

>>> NEW TECH

123

Kapitel 5 • TraceMagic

Abbildung 5.1: TraceMagic – Datenflussdiagramm/Organigramm

5.4 Die vier Hauptmodule der TraceMagic-Analyse Es gibt vier Haupt-Module für die Verarbeitung von Trace-Dateien bzw. LANPaketen: FilterMagic, FindMagic, HostMagic, SpiderMagic. ■

■

124

FilterMagic, FindMagic: Diese beiden Module dienen dem Filtern und Suchen, sie enthalten keine eigene Analyse-Intelligenz. HostMagic, SpiderMagic: Diese beiden Module sind das, was gemeinhin als Expertensystem bezeichnet wird. Die gesamte Analyse-Intelligenz von TraceMagic sitzt in diesen >>> NEW TECH

Die vier Hauptmodule der TraceMagic-Analyse

beiden Modulen. HostMagic liefert, wie der Name sagt, eher auf einzelne Teilnehmer bezogene Ergebnisse (eindimensional, stark dokumentarisch angelegt). SpiderMagic liefert eher netzwerkweite Informationen über Dialogabläufe und Fehler einschließlich ihrer Ursachen und Wechselwirkungen (wie die »Spinne im Netz«, daher SpiderMagic). Alle anderen Module von TraceMagic enthalten Hilfsfunktionen oder Hintergrundprozesse, die zwar teils auch unverzichtbar sind, aber in der Regel nicht wirklich vom Anwender direkt verwendet werden.

5.4.1

FilterMagic

FilterMagic enthält selber keine Analyse-Intelligenz, sondern setzt »nur« die Filterregeln um, die zuvor in der TraceFilter-Datenbank aktiviert wurden. FilterMagic erlaubt, aus Gigabytes von Messdaten punktgenau die LAN-Pakete herauszuziehen (und in einer gefilterten Trace-Datei des Originalformats auszugeben), die der Anwender wünscht. Im Extremfall können über 500 Filterkriterien je Durchgang aktiviert bzw. kombiniert werden – was natürlich am Ende keinen Sinn ergibt, weil die Verarbeitungsgeschwindigkeit zu sehr darunter leiden würde. Tatsache jedoch ist, dass die Kombinationsmöglichkeiten dem Anwender die Chance geben, sehr genaue Filterprofile zu schaffen, um exakt die Pakete herauszuziehen, die für den aktuellen Störfall von Belang sind. FilterMagic ist deswegen auch so wichtig, weil dadurch final der Zwang entfällt, den LAN-Analyzer mit Online-Filtern arbeiten zu lassen. Online-Filter machen blind gegenüber vielen Ursache-Wirkungs-Verhältnissen und Wechselbeziehungen, die vom jeweils aktuellen Filter weggeblendet werden. Wer die wirklich vertrackten und verwinkelten Fehler, die Microsoft Windows im Hintergrund fertig bringt, nicht kennt, hat keine Vorstellung davon, wie wirklich wichtig es ist, beim Packet-Capture ohne jeglichen Filter zu arbeiten. Nun wurden Filter in der Vergangenheit beim Online-Capture eben auch deswegen gesetzt, weil bekannt war, dass die nachträgliche manuelle Durchsicht der Messdaten nur möglich war, wenn deren Menge möglichst klein gehalten wurde. Da nunmehr TraceMagic eine perfekte und hoch leistungsfähige Offline-Filter-Engine zur Verfügung stellt, entfällt jeglicher Grund, noch mit Online-Filtern zu arbeiten. Wer immer gezielt bestimmte LAN-Pakete herausziehen will, kann das nun tun. Und wenn sich dabei im Ergebnis herausstellt, dass bestimmte Wechselbeziehungen verdächtig sind, die erst in der Gesamtschau der Messdaten erschließbar sind, so steht ja der gesamte LAN-Traffic zur Verfügung, da ohne OnlineFilter mitgelesen und abgespeichert wurde.

>>> NEW TECH

125

Kapitel 5 • TraceMagic

Somit kann nicht mehr passieren, dass Filter partiell blind machen; Filter können nunmehr nachträglich gesetzt und ausprobiert werden, wie es der Hergang der Diagnose ergibt bzw. verlangt. Hierbei muss natürlich gesehen werden, dass das Post-Filtern je nach Art und Umfang des Filters sogar extrem schnell stattfinden kann. So kann das Herausziehen aller Pakete mit einer bestimmten IP-Adresse bei 1 GB Messdaten in wenigen Minuten vollzogen sein. Das ist absolut akzeptabel. Beim Durchsuchen der LAN-Pakete bewertet FilterMagic jedes Paket einzeln. Das ist eine sichere Methode, ist aber insbesondere bei Filtern im Bereich der Name Services nicht optimal, wenn die Zahl der Fundstellen erwartungsgemäß niedrig ist. Für diesen Fall empfiehlt sich der Einsatz von FindMagic.

5.4.2

FindMagic

FindMagic ist nicht in der Lage, mit kombinierten Suchvorgaben zu arbeiten, wie dies FilterMagic kann. FindMagic erlaubt immer nur die Suche nach einem einzelnen Vorkommnis, etwa einer MAC-Adresse, IP-Adresse oder einem NetBIOSNamen. Der Vorteil von FindMagic wirkt sich dann aus, wenn nur wenige Pakete dem Suchkriterium entsprechen. Denn FindMagic durchläuft die Trace-Dateien nicht etwa Paket für Paket (wie FilterMagic), sondern betreibt eine Art von Volltext-Recherche: FindMagic blickt »flach« in die Trace-Dateien hinein und prüft, ob das Gesuchte überhaupt irgendwo vorhanden ist; wenn nicht, wird sofort in die nächste Datei geblickt (was wirklich extrem schnell geht); wenn doch, wird jetzt erst die Trace-Datei in ihre Paketstruktur zerlegt, dann direkt zum Trefferpaket gesprungen (ohne die davor liegenden Pakete zu durchlaufen) und schon wird wieder die nächste Datei durchsucht. Das alles ist bei einer eher geringen Zahl an Fundstellen dermaßen schnell, dass schon Suchläufe über mehrere GigaBytes Messdaten schneller abliefen als das Kopieren derselben Dateien von einem Verzeichnis ins andere (dies haben Versuche unter günstigen Bedingungen mehrfach ergeben). Somit wird auch das Durchsuchen immenser Datenmengen vom Zeitverhalten her vollauf akzeptabel. Wie FilterMagic verfügt FindMagic über keine eigene Analyse-Intelligenz. Der Einsatz von FindMagic erfolgt meistens dann, wenn eine HostMagicAnalyse unzulässige bzw. fremde Rechnernamen zu Tage gefördert hat (NetBIOS, WINS, DNS, NDS) oder wenn beispielsweise bestimmte Dateien als Kern eines Fehlers auftreten und alle Pakete gefunden werden sollen, die einen bestimmten Dateinamen enthalten.

126

>>> NEW TECH

Die vier Hauptmodule der TraceMagic-Analyse

5.4.3

HostMagic

HostMagic hat den Fokus, wie der Name sagt, auf dem einzelnen Endgerät, wobei teilweise Clients im Blickfeld liegen, mal Server und aktive Komponenten im Übertragungsweg (Switches, Router). Die Ergebnisse sind stark darauf ausgelegt, dem Netzwerker eine möglichst breite und tiefe Dokumentation seiner Netzwerk-Umgebung zu liefern. Da viele Fehler erst ins Netzwerk kommen, weil die Menschen über zu wenig oder zu ungenaue Dokumentationen verfügen, muss dieses Defizit möglichst schnell und einfach, aber auch so umfassend und genau wie möglich durch automatisches Durchlaufen der Messdaten behoben werden. Dies liefert HostMagic in einem bisher ungewöhnlichen Umfang. TraceMagic/HostMagic steht hier nicht im Wettbewerb zu bekannten Tools, die das online genauso oder sogar noch besser können, weil sie z.B. mit Ping, TraceRoute oder PortScan arbeiten (z.B. What’s Up Gold von IpSwitch). Hier geht es um die Kunst, mehr oder weniger dieselbe Information rein passiv aus den archivierten Messdaten zu gewinnen. Und genau das wurde bislang von keinem der Analyzer-Hersteller in wirklich großem Umfang geleistet. Der Einsatz von HostMagic erfolgt weitgehend dann, ■

■

■ ■

wenn die Netzwerk-Dokumentation unvollständig ist und die aktiven Komponenten erfasst werden sollen: Switches, Router, Firewalls (sofern sich diese bemerkbar machen); alle Sorten von Servern (File-Server, DomainServer, Datenbank-Server, Mail-Server etc.) und so weiter; wenn Anlass besteht, die Name Services zu analysieren bzw. zu dokumentieren (NetBIOS, WINS, DNS), wobei festzuhalten ist, dass HostMagic in dieser Fähigkeit vermutlich weltweit einmalig ist; wenn einfache Statistiken in Form von Verkehrstabellen verlangt sind (wer sendet/empfängt wie viel, wer mit wem wie viel?); wenn über alle Netzwerk-Teilnehmer hinweg die nötigen Adresstabellen verlangt werden: MAC-Adressen; IP-Adressen; MAC-zu-IP, IP-zu-MAC; Name-zu-IP, IP-zu-Name.

Die Erfahrung zeigt, dass HostMagic aller Analyse Anfang darstellt: Denn die Name Services von Microsoft sind immer wieder für üble Überraschungen gut und ohne Sanierung der Namensdienste haben alle anderen Maßnahmen im Netzwerk nur begrenzt Aussicht auf Erfolg. Ist dies jedoch geleistet, wird HostMagic eher in längeren Intervallen eingesetzt und die fortlaufende Analyse bzw. Qualitätskontrolle der Datenströme wird über SpiderMagic abgewickelt. Beispiel: Hätten Sie gedacht, dass ein Windows-Client auf die Idee kommen könnte, eine Zeile im Server-Login-Script umzuwandeln in eine DNS-Anfrage nach einem vermeintlichen DNS-Host wie dem folgenden? SERVERVOLUMEuser%username%.domain.com

Vermutlich nicht und doch kann so etwas schnell geschehen, wenn bestimmte, ungünstige Bedingungen auftreten. >>> NEW TECH

127

Kapitel 5 • TraceMagic

5.4.4

SpiderMagic

SpiderMagic entspricht im weitesten Sinne dem, was der Netzwerk-Techniker durch seinen LAN-Analyzer als »Expertensystem« kennt. SpiderMagic erkennt einzelne Ereignisse (z.B. TCP Retransmissions, ICMP-Meldungen), Ereignisabfolgen (Client greift auf Server zu, Server versagt den Zugriff), Ereigniskausalitäten bzw. Wechselbeziehungen (Server versagt einen Client-Zugriff und der Zugriffsversuch des Clients geht zurück auf eine bestimmte Script-Zeile einer CMD-Datei, die der Client irgendwann zuvor vom Server einlas und nun abarbeitet). Hierbei spielt eine zentrale Rolle, dass bei vielen dieser Untersuchungen die Datei-Grenzen der Trace-Files entweder keine oder nur eine mäßig einschränkende Rolle spielen. So ist SpiderMagic in der TCP/IP-Analyse in der Lage, Beziehungen zwischen IP-Paketen herzustellen, die mehrere hundert (!) Trace-Dateien auseinander liegen. Beispiel: Die IP-Pakete eines IP-Teilnehmers, der auswärts hinter einer WAN-Wolke siedelt, kommen normalerweise über einen bestimmten Verkehrsweg am Messpunkt an (bzw. vorbei). SpiderMagic erkennt in vielen (wenn nicht gar den meisten) Fällen auch bei längeren Sendepausen diese »remote hosts«, wenn sich die Verkehrswege seiner IP-Pakete inzwischen geändert haben. Um dieses leisten zu können, führt SpiderMagic immense Tabellen und Listen, um die verschiedensten Merkmale und Zustände in den Datendialogen der einzelnen Teilnehmer nachzuhalten und fortlaufend mit den jüngsten Daten zu vergleichen. Da SpiderMagic bis zu 50.000 IP-Teilnehmer auf diese Weise überwachen kann (aus den Messdaten heraus), ergeben sich sehr große, aber eben auch sehr aussagekräftige Tabellen, die am Ende eines jeden Analyse-Durchgangs als TextDatei, als CSV-Datei (Tabelle) sowie als komplette Datenbank samt Knowledgebase-Bezug abgespeichert werden. Die Mächtigkeit dieser Tabellen und Datenbanken dürfte bislang einzigartig sein. Der Leser dieses Buches kann kleine Beispiele dieser Art auf der CD-ROM finden. (Die wirklich schönen Beispiele sind leider nicht öffentlich vermittelbar, weil sie natürlich vertrauliche Kundendaten enthalten.) Weiterhin zeichnet sich SpiderMagic dadurch aus, dass nicht nur eindimensionale Ereignisse (bezugslose Einzelaktionen wie beispielsweise ICMP-Meldungen) erkannt und sichtbar gemacht werden. Das wäre langweilig und entspräche dem, was sowieso schon sattsam bekannt ist. Die hohe Kunst der Analyse besteht darin, möglichst viele Bezüge zwischen verschiedenen Ereignissen bzw. Aktionen verschiedener Teilnehmer herzustellen, um auf diese Weise auch Fehlern auf die Spur zu kommen, deren Wirkungsweise sich nicht sofort auf den ersten Blick erschließt.

128

>>> NEW TECH

Die vier Hauptmodule der TraceMagic-Analyse

Die Schwerpunkte der SpiderMagic-Analysen sind in verschiedene Sub-Module unterteilt: ■

■

■

■

■

MAC: Typische Fehler in Ethernet, Token-Ring und FDDI werden automatisch erkannt, darunter auch einige, die von gängigen Analyzern übersehen werden. Dazu zählen Paketverfälschungen, die von Switches oder Routern vorgenommen werden und bei denen, bedingt durch den Fehlerablauf, die Prüfsummen auf MAC-Ebene trotzdem stimmen. LLC und SNA: Für Kunden aus dem klassischen SNA-Umfeld (Banken, Versicherungen) ist dieses Modul sehr hilfreich. Gleichwohl ist dies natürlich ein absterbender Ast des technischen Stammbaums. TCP/IP: Dieses Modul schlägt vermutlich alles, was bisher an TCP/IP-Analyse auf dem Markt ist. In den vorigen Abschnitten wurden die entscheidenden Hinweise schon gegeben, in den späteren Abschnitten werden praktische Beispiele folgen. Die Schwerpunkte liegen auf IP, ICMP und TCP. Aus guten Gründen können während der TCP/IP-Analyse die klassischen Name Services (NetBIOS, WINS, DNS) nebenher begleitend berücksichtigt werden. Ihre eigentliche Untersuchung jedoch findet über das Modul HostMagic statt (siehe oben). Application: Die wichtigsten Client/Server-Protokolle (SMB, NCP, HTTP) werden sehr weitreichend untersucht und selbst komplexe Fehlerabläufe werden mit verschiedenen Mitteln sichtbar gemacht. Inzwischen wurde sogar ein kleines Oracle-Modul eingefügt, um in diesem speziellen Umfeld die Fehlersuche zusätzlich zu erleichtern.

Im Applikations-Bereich mit SMB, NCP, HTTP liegen die Schwerpunkte auf folgenden Funktionen: ■ ■

■

■

Erkennung aller Zugriffe der Clients, die von den Servern abgelehnt bzw. nicht korrekt bedient werden Sofern ein fehl geschlagener Zugriff auf ein vom Client durchgeführtes Script zurückzuführen ist (etwa Server-Login-Script, .CMD, .BAT) oder auf spezielle Config-Dateien (etwa .REG, .POL, NTUSER.DAT) oder auf sonstige Dateien mit spezifischen Inhalten (etwa .LNK, .DOC), so soll der Zusammenhang zwischen Script-Datei bzw. Config-Datei einerseits und Fehlzugriff andererseits nachvollziehbar sein. Die Datei-Operationen OPEN, CLOSE, READ, WRITE, RENAME, DELETE (Öffnen, Schließen, Lesen, Schreiben, Umbenennen, Löschen) sollen vollständig erkannt werden. Sämtliche File Handles (Zugriffsschlüssel für Dateien, die der Client begehrt und der Server gibt) sollen tabellarisch festgehalten werden, um die Vorgänge, die ja in den Dialogen nur mit dem File Handle durchgeführt werden, auf die Dateinamen im Klartext zurückführen zu können. Wichtige Funktionen wie LOGIN, LOGOUT, Domain-Operationen (bei NetWare beispielsweise NDS-Abfragen) sollen so weit wie möglich sichtbar und nachvollziehbar gemacht werden.

>>> NEW TECH

129

Kapitel 5 • TraceMagic

■

■

Es sollen Zusammenhänge und Wechselwirkungen zwischen verschiedenen Protokoll-Stapeln sichtbar werden: Durch möglichst übersichtliche Darstellung im Event-Log sollen bei manueller Durchsicht Querbeziehungen in den Zugriffen der verschiedenen Client/Server-Protokolle sichtbar werden. Beispiel: Ein Client sucht eine Datei erst per SMB, dann per NCP, dann per HTTP, am Ende womöglich sogar völlig verquer per DNS (das ist schon vorgekommen!). Dies soll schnell und unkompliziert nachvollziehbar sein, auch durch einfache Hilfsmittel wie Textfilter im Event-Log (ähnlich dem Unix-Befehl »grep«). Es sollen Zusammenhänge und Wechselwirkungen zwischen verschiedenen OSI-Schichten sichtbar werden: Wenn Störungen im Routing (IP) oder Abbrüche auf Transportebene (TCP) im Zusammenhang mit Applikations-Vorgängen stehen (oder umgekehrt) oder wenn physikalische Fehler Wirkung auf Applikations-Ebene zeigen, so soll das möglichst klar erkennbar sein.

Die Ergebnisausgabe erfolgt grundsätzlich in drei Formaten: ■

■

■

■

.TXT – Hierbei handelt es sich um möglichst gut lesbare Report-Dateien, die

wesentlich dem Zweck dienen, schnelle Übersicht zu erhalten. Sie können ggf. editiert bzw. mit Kommentaren versehen werden, etwa zur Versendung an Dritte, die sich mit dem Fall befassen. .CSV – Dies sind Tabellen, die zur Weiterverarbeitung in Excel etc. gedacht sind. Obwohl die Report-Datenbanken in aller Regel effizienter sind als Excel-Tabellen, muss doch gesehen werden, dass .CSV/.XLS-Dateien leichter per Mail verschickt werden können als komplette Datenbanken und dass Excel-Tabellen mit durchdachten Makros durchaus starken Nutzen entfalten können. .DB – Dies sind komplette Datenbanken mit zum Teil verknüpften Tabellen, die gezielt für den jeweiligen Analyse-Zweck entworfen wurden und zielgerichtete Abfragen erlauben. Sie sind teilweise mit der TraceMagic-Knowledgebase verknüpft und erlauben daher, sehr schnell vom Allgemeinen ins Einzelne und bis zur Erklärung bzw. zur Lösung zu kommen. .HTML – Die als TXT-Datei erzeugten Event-Logs sowie die als DB-Datenbank abgelegten Statistiken werden auf Wunsch im HTML-Format ausgegeben, automatisch mit vollem Index versehen und mit allen nötigen Quer-Verweisen (HTML-Links). Ideal zur Weitervermittlung der TraceMagic-Ergebnisse an Empfänger, die selber nicht mit dem Programm arbeiten, sondern nur an den Berichten interessiert sind.

5.5 Installation von TraceMagic Die Installation ist denkbar einfach. Das Setup-Programm gibt die LizenzBedingungen bekannt, fragt nach dem Anwendernamen (was für TraceMagic selber ohne Belang ist) und ein paar Mausklicks weiter geht's schon los: Die Dateien werden auf die Festplatte kopiert und am Ende wird gefragt, ob das Programm gestartet werden soll.

130

>>> NEW TECH

Start von TraceMagic

5.6 Start von TraceMagic Beim ersten Start wird mehr Zeit benötigt als bei allen folgenden Aufrufen. Insbesondere werden zwei WinZIP-Archive entpackt (die nicht dem SetupProgramm unterliegen, das zunächst durchgeführt worden war). Das läuft zügig ab und bedarf nur der Bestätigung der angezeigten Meldungen.

5.6.1

Das Startfenster (mit Abbruchmöglichkeit)

Mit dem Aufruf von TraceMagic.exe erscheint vor dem Hintergrund eines TraceMagic-Logos folgendes Startmenü:

Abbildung 5.2: Startmenü. Mit STOP wird das Laden von TraceMagic abgebrochen.

Es enthält allgemeine Informationen, die Lizenz-Bedingungen und vor allem die Möglichkeit, das etwas länger dauernde Laden von TraceMagic über den STOPButton abzubrechen.

>>> NEW TECH

131

Kapitel 5 • TraceMagic

5.6.2

Kleines INIT-Fenster

Während TraceMagic geladen wird, erscheint ein kleines Init-Fenster, das während des Ladevorgangs wächst.

Abbildung 5.3: Das kleine INIT-Fenster beim Laden von TraceMagic

Es dient allein dazu, den je nach Prozessorleistung mal schneller, mal langsamer laufenden Ladevorgang anzuzeigen, indem das Fenster an Länge zunimmt, je weiter das Laden voranschreitet.

5.6.3

Lizenz-Hinweis (Demo-Version oder Lizenz-Version)

Als Nächstes erscheint ein Hinweisenster, das den Lizenz-Status anzeigt. Nach der Installation arbeitet TraceMagic als Demo-Version, was bedeutet: Alle Funktionen sind voll nutzbar, aber von jeder Trace-Datei werden nur die jeweils ersten 10.000 Pakete untersucht (die überzähligen werden je TraceDatei übersprungen).

Abbildung 5.4: Lizenz-Hinweis: Demo-Level (nicht lizenziert)

Die Lizenzierung läuft in Schritten von jeweils einer Million LAN-Paketen ab, damit wird die Zahl der Pakete festgelegt, die je Analyse-Durchgang nonstop verarbeitet werden können. Auf diese Weise ist der Lizenz-Preis für kleine Unternehmen (mit wenig Datenverkehr) niedriger als für große Unternehmen (mit viel Datenverkehr). Eine »Light«-Lizenz hat etwas abgespeckten Funktionsumfang, insbesondere die mächtigen Filterfunktionen stehen in der »Light«-Lizenz nicht zur Verfügung (die Filterfunktionen treten in der Menüführung als TRACE:FILTER bzw. FILTER:MAGIC auf), ebenso wie die Funktionen zur Anonymisierung von Messdaten und Ergebnisreports (TRACE:ANON).

132

>>> NEW TECH

Start von TraceMagic

Abbildung 5.5: Lizenz-Hinweis: »Light«-Lizenz; Verarbeitung von bis zu fünf Millionen LAN-Paketen je Analyse-Durchgang

Eine »Professional«-Lizenz mit bis zu fünf Millionen LAN-Pakete meldet sich wie folgt:

Abbildung 5.6: Lizenz-Hinweis: »Professional«-Lizenz, begrenzt auf fünf Millionen LAN-Pakete

Eine »Professional«-Lizenz mit bis zu fünf Millionen LAN-Paketen meldet sich wie folgt:

Abbildung 5.7: Lizenz-Hinweis: »Professional«-Lizenz, zugelassen für unbegrenzt viele LAN-Pakete

5.6.4

Prüfung der Datenbanken

Es folgt eine kurze Zwischenphase, in welcher die Datenbank-Tabellen überprüft und ggf. neu erzeugt werden.

Abbildung 5.8: Meldung während der Überprüfung der Datenbank

>>> NEW TECH

133

Kapitel 5 • TraceMagic

5.6.5

Benutzeranmeldung

TraceMagic verfügt über eine eigene Benutzerverwaltung. Dies dient nicht nur als Zugangshindernis, sondern vielmehr der Zuordnung verschiedener AnalyseVorgänge zum Bearbeiter (Stichwort: Revisionsfähigkeit). Unmittelbar nach der Installation ist nur ein Benutzername aktiv, das ist ADMIN und das Passwort lautet ebenfalls ADMIN. Sofort nach vollständigem Laden des Programms können weitere Benutzernamen eingerichtet werden.

Abbildung 5.9: Benutzeranmeldung (anfänglich immer mit ADMIN)

5.6.6

Auswahl des Analyzer-Trace-Formats

Sodann erfolgt eine Vorauswahl des Datei-Formats, entsprechend dem Analyzer, dessen Capture-Files verarbeitet werden sollen. Diese Vorauswahl ist nicht bindend, sie kann jederzeit in TraceMagic zu späterer Zeit geändert werden, je nach Bedarf. Technisch gesehen setzt diese Auswahl lediglich einen Datei-Filter für die verschiedenen Datei-Auswahlfenster des Programms. Daher werden auch andere Formate für Text-Dateien zur Auswahl angeboten (.TXT, .DOC etc.) (siehe Abbildung 5.10).

5.6.7

Funktionswahl: Trace-Analyse oder Report-Viewer

Wenn es nur darum geht, bereits vorhandene Analyse-Reports von TraceMagic zu betrachten bzw. weiterzuverarbeiten, so wird hier REPORT VIEWER gewählt. Sollen Trace-Dateien verarbeitet werden, ist ANALYSIS zu wählen. Diese Auswahl ist keine endgültige Festlegung. Wird ANALYSIS gewählt, kann jederzeit der VIEWER aufgerufen werden. Wird dagegen jetzt der VIEWER gewählt, springt das Programm nach dessen Beendigung in den Analyse-Modus (siehe Abbildung 5.11).

134

>>> NEW TECH

Start von TraceMagic

Abbildung 5.10: Datei-Filter mit Analyzer-Formaten

Abbildung 5.11: Funktionsauswahl: TRACE ANALYSIS oder REPORT VIEWER

Mit der Installation wird übrigens auch ein reines REPORT VIEWER-Programm mitgeliefert, das keiner Analyse fähig ist, dessen Laden dafür aber sehr viel schneller abläuft als das Laden des vollen Hauptprogramms.

>>> NEW TECH

135

Kapitel 5 • TraceMagic

Mit Bestätigung durch OK ist der Startvorgang abgeschlossen, TraceMagic ist voll betriebsbereit.

5.6.8

Datei-Auswahlmenü: Welche Traces sollen verarbeitet werden?

Es erscheint zuletzt das Menü zur Auswahl der Trace-Dateien, die verarbeitet werden sollen. Ist das geschehen, bleibt das zentrale Funktionsmenü von TraceMagic auf dem Bildschirm stehen:

5.6.9

Trace-Menü: Die zentrale Schaltstelle

Die zentrale Schaltstelle von TraceMagic ist das so genannte TRACE MENU. Im großen Fenster links erscheinen die Trace-Dateien, die im vorigen Schritt zur Verarbeitung ausgewählt wurden, im rechten kleinen Auswahlfenster erscheinen sämtliche Funktionen, die mit der Verarbeitung bzw. Analyse der TraceDateien zu tun haben.

Abbildung 5.12: Das TRACE MENU mit allen Verarbeitungsfunktionen (rechts)

5.7 Der Start von SpiderMagic Die beiden Haupt-Module in der Trace-Analyse sind HostMagic und SpiderMagic (siehe oben). Hier soll nun beispielhaft der Start von SpiderMagic samt der anschließenden Betrachtung der Ergebnisse erläutert werden.

136

>>> NEW TECH

Der Start von SpiderMagic

5.7.1

Auswahl der Unterfunktionen

Dazu können verschiedene Sub-Module einzeln gewählt werden: MAC, LLC/ SNA, TCP/IP, Application. In diesem Beispiel wird das wirklich zentrale Modul TCP/IP gewählt, bei dem die Module MAC und APPLICATION parallel mitlaufen können.

Abbildung 5.13: Das Schaltpult für die IP-Funktionen

In aller Regel empfiehlt es sich, die Standardeinstellungen zu belassen. Erst bei genauerer Kenntnis der Arbeitsweise von TraceMagic sollte versucht werden, einzelne Unterfunktionen auszuschalten, indem das Häkchen in der jeweiligen Checkbox entfernt wird. Die Abbildung der Funktion FILE RECONSTRUCTION (auch: rc.files) zeigt die Einstellungen für eine bisher in der Welt der LAN-Analyse einmalige Spezialfunktion: Wann immer ein Client-PC von einem Server eine Datei lädt, kann der Inhalt dieser Datei rekonstruiert und im Projektverzeichnis der TraceMagicAnalyse abgelegt werden. Der wichtige Vorteil dieser Funktion ist nicht, heimlich Dateien mitlesen zu können (die Dateien werden daher nicht im Originalformat wiederhergestellt, sondern in einem dokumentarischen Format); der Vorteil liegt darin, dass fehlschlagende Zugriffe von Clients auf Server auf Anweisungen in Dateien zurückgeführt werden können, etwa auf Script-Dateien (etwa Login-Script, .CMD, .BAT), Konfigurationsdateien (etwa .POL, .REG, .DAT) oder sonstige Dateien (etwa .DOC, .LNK). >>> NEW TECH

137

Kapitel 5 • TraceMagic

Abbildung 5.14: Das Schaltpult für die TCP-Funktionen

5.7.2

Start der SpiderMagic-Analyse mit TCP/IP

Um die Analyse zu starten, muss in der jeweiligen Funktionsgruppe der STARTButton betätigt werden.

5.7.3

Standardabfragen beim Start eines Analyse-Moduls

Sodann folgen einige Abfragen, die einerseits der Arbeitsorganisation dienen, andererseits der Reservierung von System-Ressourcen für die Adresstabellen etc.

5.7.4

Auswahl: Trace-Alias und Vorgangstitel

Als Erstes erfolgt die Aufforderung, den nun folgenden Analyse-Durchgang einem so genannten Trace-Alias zuzuordnen. Der Trace-Alias ist eine willkürliche Größe, die einen Kunden bezeichnen kann, ein Subnetz, ein Netzwerk-Problem, irgend etwas dieser Art. Der Zweck liegt darin, dass in der TraceMagic-Datenbank ein Ordnungskriterium hinterlegt wird, nach dem später sortiert oder gesucht werden kann.

138

>>> NEW TECH

Der Start von SpiderMagic

Abbildung 5.15: Das Schaltpult für die Namensdienst-Funktionen

Über die Schaltfläche TRACE:ALIAS kann die Datenbank-Tabelle der Alias-Einträge aufgerufen werden, um entweder einen neuen Eintrag anzulegen oder um aus den bestehenden Einträgen einen auszuwählen. Im Moment ist der Alias-Eintrag KOBLENZ ausgewählt (offenkundig handelt es sich um die Messdaten eines Netzwerkes in Koblenz). Der Vorgangstitel beschreibt Sinn und Zweck der nun anstehenden Analyse und wird so wie eingegeben in der Datenbank abgelegt.

5.7.5

Auswahl: Trace-Filter (ja oder nein)

Es kann bei jedem Analyse-Vorgang ein Vorfilter gesetzt werden. »Vorfilter« bedeutet: Bevor ein LAN-Paket der Verarbeitung zugeführt wird, kann geprüft werden, ob es überhaupt berücksichtigt werden soll. Wird ein Filter gesetzt, werden nur genau die Pakete »angefasst«, die auch den Filterkriterien entsprechen. Wird kein Filter gesetzt, werden alle Pakete berücksichtigt. Die Filtermethoden werden an anderer Stelle erläutert.

>>> NEW TECH

139

Kapitel 5 • TraceMagic

Abbildung 5.16: Das Schaltpult für die Spezialfunktion RECONSTRUCTED FILES

Abbildung 5.17: Zuordnung von Trace-Alias und Vorgangstitel

140

>>> NEW TECH

Der Start von SpiderMagic

Abbildung 5.18: Abfrage, ob Filter gesetzt werden sollen (oder nicht)

5.7.6

Auswahl: Größe der IP-Adresstabelle

TraceMagic erzeugt zum Teil erheblich große Hintergrundtabellen, um die verschiedenen Analyse-Funktionen überhaupt zu ermöglichen. Da Microsoft Windows während der Trace-Analyse Probleme bekommen kann, die wachsenden Tabellen mit zusätzlichem Hauptspeicherplatz zu versorgen, wird die Tabellengröße vorab bestimmt, damit die Speicher-Ressourcen noch vor dem Einlesen der ersten Trace-Datei belegt werden können.

Abbildung 5.19: Reservierung von Hauptspeicher-Ressourcen für die IP-basierenden Analyse-Tabellen

>>> NEW TECH

141

Kapitel 5 • TraceMagic

Das erste Mal wird man geneigt sein, einen hohen Wert zu wählen, sobald man das eigene Netzwerk gut kennt, wird man einen angemessenen Wert wählen. Sollten in den Messdaten viele HTTP-Zugriffe von lokalen Clients ins Internet zu finden sein, kann die Zahl der IP-Adressen dramatisch ansteigen – je nachdem, welche und wie viele Internetseiten angesprochen wurden. Es kann geschehen, dass bei mangelnden Speicher-Ressourcen nicht die volle Zahl der gewünschten Tabellenplätze eingerichtet werden kann. In diesem Falle erscheint eine Meldung, für wie viele Tabellenplätze die Ressourcen ausreichen.

5.7.7

Vorbereitung der Report-Datenbanken (1)

Sodann erscheint ein rotes Mitteilungsfenster mit der Meldung, dass nunmehr die ersten Ergebnisdatenbanken eingerichtet werden.

Abbildung 5.20: Mitteilung darüber, dass die Report-Datenbanken eingerichtet werden

Je nachdem, wie viele System-Ressourcen frei sind, kann dieser Vorgang mal schneller, mal langsamer ablaufen.

5.7.8

Auswahl: Größe der TCP History-Tabelle

Um auch über die Grenzen der Trace-Dateien hinweg TCP Retransmissions (und verwandte Ereignisse) zuverlässig erkennen zu können, wird eine Tabelle eingerichtet, in der die wichtigsten Werte der zuletzt gesehenen TCP/IP-Header abgelegt werden. Vorgeschlagen wird, dass die jeweils 1.000 letzten TCP/IP-Pakete im Hauptspeicher gehalten werden; erfahrungsgemäß reicht dies aus, um den erwünschten Zweck zu erreichen. Im Falle von WAN-Kommunikation jedoch (lange Laufzeiten der TCP-Dialoge zwischen Client und Server) könnte angeraten sein, den Wert auf 10.000 TCP/IP-Header hochzusetzen. Es muss darauf hingewiesen werden, dass diese History-Tabelle nicht der einzige Mechanismus ist, um die Grenzen der Trace-Dateien möglichst effizient aufzuheben bzw. unwirksam zu machen. Alle anderen Hintergrundvorgänge jedoch, die diesem Ziel dienen, können von außen nicht beeinflusst werden. Die History-Tabelle ist deswegen in ihrer Größe beeinflussbar, weil der bei WAN-Kommunikation ggf. erforderliche Wert von 10.000 TCP/IP-Headern die Verarbeitungsdauer von TraceMagic erheblich verlängern kann.

142

>>> NEW TECH

Der Start von SpiderMagic

Abbildung 5.21: Bestimmung der Größe der TCP History-Tabelle

Dieser Mechanismus der nachhängenden »Erinnerung« an die jeweils letzten TCP/IP-Pakete ist entscheidend, um TCP Retransmissions zu erkennen, bei denen die Erstübertagung beispielsweise in Trace-Datei Nummer 442 liegt, die Zweitübertragung aber in der folgenden Trace-Datei Nummer 443. Die Hinweise in der Fußzeile (OK, ERROR) weisen darauf hin, dass die Analyse von TCP mit Blick auf die Retransmissions nur gelingen kann, wenn die Trace-Dateien in der Reihenfolge ihres Entstehens verarbeitet werden. Dies zielt auf den LANdecoder32 (Triticom), dessen Trace-Dateien zwar durchnummeriert werden, dessen Nummerierung aber nicht durchgängig dreistellig ist (wie es bei maximal 255 Trace-Dateien nötig wäre). Um bei LANdecoder32Trace-Dateien die richtige Verarbeitungsreihenfolge zu erreichen, ist die Zusatzfunktion TRACE-COUNTER zu benutzen; sie nimmt die erforderlichen Umbenennungen in den Dateinamen vor.

5.7.9

Auswahl: Trefferpakete in neue Trace-Datei schreiben?

Sodann erfolgt eine wirklich zentrale Abfrage bzw. Entscheidung: Sollen alle LAN-Pakete, die sich im Sinne der Analyse als von Belang herausstellen, in eine neue (quasi gefilterte) Trace-Datei geschrieben werden? Dahinter verbirgt sich folgender Vorgang: Es wird eine IP-Analyse gestartet. Im Zuge der Analyse werden IP-RoutingFehler gefunden. Dann wird jedes IP-Paket, das an Routing-Fehlern beteiligt ist oder das die Erkennung solcher Fehler begünstigt, aus den Original-Traces heraus kopiert und in die neue Report-Trace-Datei geschrieben.

>>> NEW TECH

143

Kapitel 5 • TraceMagic

Abbildung 5.22: Diese Abfrage nach Erzeugung einer neuen Trace-Datei mit den Trefferpaketen sollte unbedingt mit JA beantwortet werden.

Der Vorteil ist: ■

■ ■

Aus Millionen von LAN-Paketen (der Original-Traces) werden die paar Zehntausend (oder wie viel auch immer) herausgezogen, auf die es im Sinne der Erkenntnis wirklich ankommt. Dieses Restsubstrat kann mit dem LAN-Analyzer völlig unproblematisch eingelesen, untersucht, weiterverarbeitet werden. Der Clou dabei ist: Derselbe Analyzer, der nicht in der Lage war, hunderte von Trace-Dateien automatisch zu verarbeiten, bekommt nun ein quasi vorverdautes Substrat geboten, das er mit seinem eigenen Expertensystem optimal durchsuchen kann.

Mit dem Mechanismus, alle Trefferpakete im Sinne der Analyse in neue TraceDateien zu schreiben, ist ein extrem wichtiger Zusatzmechanismus verbunden: Für jedes Trefferpaket (auch: Treffer-Frame) wird im Event-Log eine eigene Ereigniszeile abgelegt; ggf. werden sogar mehrere Ereigniszeilen miteinander verbunden, um Zusammenhänge zwischen weit auseinander liegenden Paketen sichtbar zu machen. Diese Event-Log-Dateien folgen immer derselben Namens-Konvention: TM.HIT.FRAMES.*.TXT

Diese Event-Log-Dateien stellen ein zentrales Medium der LAN-Analyse dar: ■

144

Sie weisen nach, an welcher Stelle in den Original-Traces die Treffer-Frames ursprünglich liegen. Insofern erfüllen sie die zur Revisionsfähigkeit notwendige Index-Funktion.

>>> NEW TECH

Der Start von SpiderMagic

■

■

■

Sie weisen den Paketinhalt aus, auf den es im Sinne der Analyse wirklich ankommt, ungeachtet des OSI Layers oder des Protokoll-Stapels. Das kann kein LAN-Analyzer leisten, weil Analyzer in viel zu starren Schemata arbeiten. Sie stellen Verbindungen her zwischen zum Teil sogar Tausende von Frames auseinander liegenden Paketen und machen das durch paarweise Darstellung deutlich. Beispiel: Enthält Paket Nummer 392 die Erstübertragung eines TCP-Headers und enthält Paket Nummer 18.389 die Zweitübertragung (Wiederholungsübertragung = Retransmission), so werden in der Event-Log-Datei TM.HIT.FRAMES.*.TXT beide Pakete gemeinsam aufgeführt, um den Zusammenhang zu verdeutlichen; eine Klammer links und rechts zeigt deutlich, dass bewusst ein Zusammenhang hergestellt wird. Nur die Event-Log-Dateien zeigen den chronologischen Ereignisablauf von Fehlern oder Vorgängen. Alle anderen Report-Dateien von TraceMagic enthalten Tabellen, Statistiken, Zusammenfassungen.

Daher gilt: In praktisch jedem Falle sollte die Frage nach der »neuen Trace Datei« mit Ja beantwortet werden. Die Zusatzfrage, neben dem Standard-Event-Log noch separate Special-EventLogs auszugeben, kann je nach Bedarf beantwortet werden. Es geht schlicht um die Frage, ob aus dem zentralen Event-Log TM.HIT.FRAMES.*.TXT je nach Protokollerwähnung die Textzeilen in zusätzliche, protokollorientierte Log-Dateien ausgegeben werden sollen. Wird mit Ja geantwortet, verlangsamt sich etwas die Analyse-Geschwindigkeit; die nachträgliche Durchsicht der Event-Logs wird jedoch erheblich erleichtert, da durch die Separat-Logs größere Übersicht über abgegrenzte Protokollbereiche möglich ist. Name und Verzeichnis der neu erzeugten Trace-Datei werden unmittelbar nach Start der Analyse mitgeteilt (siehe unten).

5.7.10 Auswahl: Trefferpakete in Text-Dekodierungen ausgeben? Für Anwender, die selber keinen Analyzer haben und die folglich die Trefferpakete gar nicht per Analyzer betrachten können, wird die einfache Möglichkeit geboten, den Inhalt der Trefferpakete in einfachen Text-Dekodierungen auszugeben. Diese Funktion sollte nicht verwendet werden, wenn ein Analyzer vorhanden ist. Denn diese Funktion kostet deutlich Verarbeitungszeit, Festplattenplatz und Geduld beim Lesen der Ergebnistexte, die wirklich sehr einfach gehalten sind und nur das Notdürftigste bieten.

>>> NEW TECH

145

Kapitel 5 • TraceMagic

Abbildung 5.23: Diese Abfrage nach Erzeugung von Text-Dekodierungen sollte nur im Notfall (dem Fehlen eines Analyzers) mit JA beantwortet werden.

5.7.11 Vorbereitung der Report-Datenbanken (2) Sodann erscheint erneut das rote Mitteilungsfenster mit der Meldung, dass Ergebnis-Datenbanken eingerichtet werden.

Abbildung 5.24: Mitteilung darüber, dass die Report-Datenbanken eingerichtet werden

5.7.12 Auswahl: Endgültiger Start mit den gewählten Einstellungen Bevor es nun endlich los geht, wird noch einmal gefragt, ob mit den vorgenommenen Einstellungen auch tatsächlich gestartet werden soll. Mit der Auswahl von JA – START beginnt endgültig die Analyse: Alle ausgewählten Trace-Dateien werden nunmehr automatisch verarbeitet.

146

>>> NEW TECH

Report-Dateien: Jeder Durchgang erhält sein eigenes Verzeichnis

Abbildung 5.25: Abfrage zum endgültigen Start

5.8 Report-Dateien: Jeder Durchgang erhält sein eigenes Verzeichnis Die Ausgabe der Ergebnis-Dateien folgt einer strikten Struktur, um bestmögliche Übersichtzu gewährleisten.

5.8.1

Die neu erzeugte Trace-Datei samt zugehörigem Event-Log

Unmittelbar nach dem endgültigen Start erscheint eine Meldung, die darauf hinweist, in welchem neu erzeugten Unterverzeichnis die Report-Dateien abgelegt werden (siehe Abbildung 5.26). Diese Meldung wird automatisch eingeblendet und verschwindet auch wieder automatisch (also ohne Benutzereinwirkung). Hierbei zeigt sich die Ablagelogik von TraceMagic: ■ ■

Die Ergebnis-Dateien werden in Unterverzeichnissen abgelegt, die ihrerseits im Verzeichnis der Original-Traces erzeugt werden. Im Namen dieser Unterverzeichnisse spiegelt sich wider, welche Analyse dort ihre Daten abgelegt hat.

Im vorliegenden Beispiel: TM.0020.SM.IP.SMB.NCP.HTTP.Oracle.RC.PS

>>> NEW TECH

147

Kapitel 5 • TraceMagic

Abbildung 5.26: Hinweis auf Name und Ort der neu erzeugten Trace-Datei (sowie aller anderen ReportDateien)

Das will sagen: ■ ■ ■ ■ ■ ■ ■

TM = TraceMagic 0020 = Zwanzigster Analyse-Durchgang über diese Trace-Dateien SM = Haupt-Modul war SpiderMagic IP = Gewählte Analyse-Unterfunktion war TCP/IP SMB.NCP.HTTP.Oracle.RC.PS = Zusatzfunktionen aus Layer 7 RC = Reconstructed Files (übertragene Dateien werden rekonstruiert) PS = Port Statistics (spezielle TCP-Port-Auswertung)

Die langen Verzeichnisnamen mögen ungewöhnlich sein, helfen aber immens, wenn man über den MS Windows-Explorer auf die Festplatte blickt (und nicht über die TraceMagic-Menüs).

5.8.2

Die Report-Datenbanken

Die Report-Datenbanken werden innerhalb des Ergebnisverzeichnisses in dem weiteren Unterverzeichnis namens ..\db abgespeichert.

5.8.3

Die »reconstructed files«

Die ggf. rekonstruierten Dateien (aus den LAN-Paketen heraus gelesen und separat abgelegt) werden innerhalb des Ergebnisverzeichnisses in dem weiteren Unterverzeichnis namens ..\rc.files abgespeichert.

148

>>> NEW TECH

TraceMagic während der laufenden Analyse

5.9 TraceMagic während der laufenden Analyse In gewisser Weise ist TraceMagic darauf ausgerichtet, nunmehr so lange zu laufen und zu arbeiten, bis alle Trace-Dateien verarbeitet sind. Wird dieser Vorgang kurz vor Feierabend gestartet, kann man ohne Mühe am nächsten Morgen die Reports zur Kenntnis nehmen. (Zu den Reports: Siehe unten.) Das aber kann ja nicht die zwingende Variante sein. Also gibt es die Möglichkeit, in Vorausschau auf die endgültigen Ergebnisse quasi »live« zu erleben, was TraceMagic gerade »sieht« bzw. verarbeitet. Hierzu gibt es verschiedene Möglichkeiten.

5.9.1

Trace-Analysis: Einfache Aktivitätsanzeige

Um auch über weite Entfernung (quer durchs Rechenzentrum beispielsweise) noch gut erkennen zu können, ob TraceMagic arbeitet (oder schon fertig ist), zeigen große, blaue Fortschrittsbalken an, wie weit die Verarbeitung inzwischen gediehen ist.

Abbildung 5.27: Aktivitätsanzeige, während TraceMagic arbeitet

>>> NEW TECH

149

Kapitel 5 • TraceMagic

Die Fortschrittsbalken sind wie folgt zu lesen: ■ ■

■

■

■

■

Der erste Balken von oben zeigt an, wie viele Trace-Dateien insgesamt bereits abschließend verarbeitet wurden. Der zweite Balken von oben zeigt an, dass bzw. wie die aktuelle Trace-Datei in den Hauptspeicher eingeladen wird; die Zahl rechts davon weist die Datei-Größe in Bytes aus. Der dritte Balken von oben zeigt an, dass bzw. wie die aktuelle Trace-Datei indiziert wird, das heißt wie sie in ihre Paketstruktur zergliedert wird (sonst wären die einzelnen LAN-Pakete gar nicht identifizierbar). Rechts davon wird die Zahl der LAN-Pakete angezeigt, die in der Trace-Datei abgelegt sind. Der vierte Balken von oben (und somit der letzte) zeigt den Verarbeitungsfortschritt an, der in der aktuellen Trace-Datei erreicht ist. Rechts davon wird die erreichte Paketposition angezeigt. Die fünfte Ziffer rechts (von oben gesehen) zeigt an, wie viele LAN-Pakete insgesamt (über alle Trace-Dateien hinweg) bis zum aktuellen Zeitpunkt verarbeitet wurden. Die sechste Ziffer rechts (von oben gesehen) zeigt an, wie viele LAN-Pakete als Trefferpakete in die neu erzeugte Ergebnis-Trace-Datei geschrieben wurden. (Diese Zahl ist allgemein ein zuverlässiger Indikator dafür, ob die Analyse ertragreich war oder nicht.)

5.9.2

Trace-Analysis: Aufruf der Ergebnis-Datenbank

Die Schaltfläche mit dem Tabellen-Symbol gibt den Weg frei zum Aufruf der Ergebnis-Datenbank, die auch schon während der Analyse aufgerufen werden kann. Der Aufruf der Ergebnis-Datenbank (Trace:Statistics) kann sinnvoll sein, um bei einer sehr lange laufenden Analyse per Zwischenergebnis abzufragen, ob sichweiteres Warten lohnt oder nicht. Allerdings kostet die Aktivierung der Ergebnis-Datenbank noch während laufender Analyse System-Ressourcen und ggf. erheblich Zeit (weil die DatenbankTabellen in festen Intervallen aktualisiert werden); daher sollte entweder ganz darauf verzichtet oder der Aufenthalt doch wenigstens zeitlich begrenzt werden. Die Ergebnis-Datenbank steht am Ende der Analyse ohne jede Einschränkung zur Verfügung (siehe unten).

5.9.3

Trace-Events: Aufruf des Event-Logs

Völlig unproblematisch, dafür aber sehr effektiv, ist der Aufruf des Event-Logs. Hierbei handelt es sich um die Vorausschau auf den Inhalt der Report-Datei TM.HIT.FRAMES.*.TXT (siehe oben). Wählen Sie das Registerblatt Trace:Events und starten Sie die Darstellung des Event-Logs mittels Mausklick auf die entsprechende START-Schaltfläche. In der Folge beginnt die Ausgabe von Textzeilen in dem Sichtfenster.

150

>>> NEW TECH

TraceMagic während der laufenden Analyse

Um das Sichtfenster zu vergrößern, führen Sie einen Mausklick auf der rechten Schaltfläche aus, die mit dem Brillen-Symbol auf das große Trace:Event-Fenster verweist. Sodann erscheint folgende Darstellung:

Abbildung 5.28: Trace-Events/Event-Log: Fenster mit allen Meldungen

Neben der Gesamtdarstellung können verkürzte Darstellungen mit Fokus auf die verschiedenen Protokolle aufgerufen werden.

Abbildung 5.29: Trace-Events/Event-Log: Fenster mit den Analyse-Meldungen zu IP

>>> NEW TECH

151

Kapitel 5 • TraceMagic

Abbildung 5.30: Trace-Events/Event-Log: Fenster mit den Analyse-Meldungen zu ICMP

Abbildung 5.31: Trace-Events/Event-Log: Fenster mit den Analyse-Meldungen zu TCP

152

>>> NEW TECH

TraceMagic während der laufenden Analyse

Abbildung 5.32: Trace-Events/Event-Log: Fenster mit den Analyse-Meldungen zu NCP

Abbildung 5.33: Trace-Events/Event-Log: Fenster mit der Konfiguration der Analyse-Meldungen >>> NEW TECH

153

Kapitel 5 • TraceMagic

Abbildung 5.34: Trace-Events/Event-Log: Fenster mit den Analyse-Meldungen zu »Citrix«

Die verschiedenen Protokollfenster können aktiviert und deaktiviert werden, um Verarbeitungszeit zu sparen (die Textfenster können ggf. spürbar Zeit kosten). Dafür gibt es die Config-Seite. Auf dieser können nicht nur Ein/Aus-Schalter betätigt werden, sondern auch Textfilter gesetzt werden. Im vorliegenden Beispiel wird ein Filter auf alle Vorkommnisse von »Citrix« gesetzt: Diese Vorausschau auf die Event-Log-Dateien hat den großen Vorteil, dass man noch während der Verarbeitung ein gutes Bild davon gewinnen kann, was einen ganz am Ende erwartet. Manchmal könnte man glatt vergessen, dass man nicht online an der LANLeitung hängt, sondern »nur« aus der Konservendose lebt.

5.10 Trace-Reports: Abschlussreport-Dateien erzeugen Einige Report-Dateien werden fortlaufend geschrieben (darunter TM.HIT. FRAMES.*.TXT), andere werden erst ganz am Ende erzeugt, so die Datenbanken und die CSV-Dateien (Tabellen). Es ist dringend anzuraten, das Schreiben der Report-Dateien nicht zu unterbrechen, da die Ergebnisse sonst unvollständig und daher womöglich nicht mehr sinnvoll sind.

154

>>> NEW TECH

Trace-History: Datenbank aller vergangenen Analyse-Vorgänge

Sind die Trace-Reports geschrieben, erscheint das Datenbank-Fenster der so genannten Trace-History.

5.11 Trace-History: Datenbank aller vergangenen AnalyseVorgänge Die Trace-History-Datenbank enthält ... ■ ■ ■ ■

... Verweise auf sämtliche Trace-Dateien, die je verarbeitet wurden; ... Verweise auf sämtliche Report-Dateien, die dabei erzeugt wurden; ... Verarbeitungstitel, zugeordneten Trace-Alias, Zeitangaben; ... Memo-Felder zur Eingabe von Benutzerkommentaren.

Die Trace-History soll dazu dienen, dem Anwender sämtliche Analyse-Vorgänge der Vergangenheit zugänglich zu machen. So kann auch eine Vielzahl von Analyse-Durchgängen über Wochen und Monate hinweg geordnet verwaltet bzw. genutzt werden.

5.12 Die Report-Dateien und die Ergebnis-Datenbank Alle Analyse-Vorgänge werden in der History-Datenbank festgehalten, um sie nachträglich einsehen zu können.

5.12.1 TraceHistory: Summary In der Übersichtstabelle Summary werden die Vorgangstitel der AnalyseVorgänge sowie Datum, Uhrzeit, Bearbeiter und TraceAlias (zu TraceAlias: siehe unten) angezeigt (siehe Abbildung 5.35).

5.12.2 TraceHistory: Details Der Analyse-Vorgang, der in der Übersichtstabelle ausgewählt wurde, wird im zweiten Fenster Details genauer dargestellt. Neben allgemeinen Angaben zu Analyzer, Trace-Format und dergleichen finden sich zwei Tabellenfenster: ■ ■

Links: Diese Tabelle listet die Trace-Dateien auf, die untersucht wurden. Rechts: Diese Tabelle listet die Ergebnis-Dateien aus.

>>> NEW TECH

155

Kapitel 5 • TraceMagic

Abbildung 5.35: TraceHistory: Summary

Es gibt einige Ergebnis-Dateien, die nicht in der rechten Tabelle ausgewiesen werden, weil sie nicht im engeren Sinne Befunde erhalten. Diese hier nicht aufgeführten Dateien liegen in weiteren Unterverzeichnissen des TraceMagicAnalyse-Verzeichnisses und heißen db (Datenbank-Dateien) sowie rc.files (Reconstructed Files). Bei den »reconstructed files« handelt es sich z.B. um Script-Dateien (.BAT, .CMD etc.), die von TraceMagic aus den Datenübertragungen herausgelesen und in dokumentarischer Form rekonstruiert wurden. Die Abbildungen zeigen die verschiedenen Ergebnis-Dateien einer SpiderMagicUntersuchung; zu den wichtigsten Ergebnis-Dateien gehören die markierten Dateien TM.HIT.FRAMES.01.~.001.LOG.TXT (das Event-Log der Analyse mit allen Einzelnachweisen, chronologisch geordnet) sowie TM.SM.SpiderMagic.TABLES.~~IP~~.TXT (sämtliche statistischen Befunde der TCP/IPAnalyse). Der Button mit dem Festplatten-Symbol erlaubt den Aufruf des Explorers von MS Windows innerhalb des Ergebnisverzeichnisses des aktuellen AnalyseProjekts. Es erlaubt Zugriff auf alle Ergebnis-Dateien sowie auf zusätzliche Unterverzeichnisse; hier ist bei SpiderMagic-Auswertungen auf Appl. Layer das Verzeichnis rc.files zu nennen: Hier liegen die dokumentarischen Rekonstruktionen von Dateien, die von Netzwerk-Clients auf Servern gelesen wurden.

156

>>> NEW TECH

Die Report-Dateien und die Ergebnis-Datenbank

Abbildung 5.36: TraceHistory: Details (1)

Abbildung 5.37: TraceHistory: Details (2)

>>> NEW TECH

157

Kapitel 5 • TraceMagic

Abbildung 5.38: TraceHistory: Details/Explorer im Projektverzeichnis (1)

Abbildung 5.39: TraceHistory: Details/Explorer im Projektunterverzeichnis rc.files (2)

158

>>> NEW TECH

Die Report-Dateien und die Ergebnis-Datenbank

Im Verzeichnis rc.files sind »reconstructed files« abgelegt: dokumentarisch rekonstruierte Dateien, die in den Client/Server-Übertragungen aufgefunden wurden. Im aktuellen Beispiel ist zu sehen, dass der Server IP = 195.10.16.8 mehrfach an den Client IP = 192.168.2.195 die Datei ni5_FH.bat herausgegeben hat – was sich übrigens dadurch erklärt, dass Batch-Dateien seitens der Clients zeilen- oder abschnittsweise angefordert und gelesen werden. Auf diese Weise können zum Beispiel Konfigurationsfehler der Clients nachgewiesen werden, insofern sie auf falsche oder ungewollte Anweisungen in den Batch-Dateien zurückgehen.

5.12.3 TraceHistory: EventFilter Dieses Fenster bietet den Aufruf der EventFilter-Funktion an. Diese Funktion dient dazu, mit Textfiltern aus dem Event-Log gezielt bestimmte Ereignisnachweise herauszufiltern. Außerdem können die Text-Dateien der Event-Logs in HTML-Dateien umgewandelt werden, wobei frei definierbare Ereignis- und Fehler-Einträge farbig markiert werden können. Diese Möglichkeit erhöht die Übersichtlichkeit sowie die Fähigkeit, Dritten gegenüber schnell die wesentlichen Inhalte darzustellen.

Abbildung 5.40: TraceHistory: EventFilter

>>> NEW TECH

159

Kapitel 5 • TraceMagic

5.12.4 TraceHistory: Memo Im Memo-Feld kann der Bearbeiter seine eigenen Angaben machen. Wird das Analyse-Projekt an Dritte weitergegeben (was bedeutet: das Unterverzeichnis des Analyse-Projekts wird weitergegeben), so sind diese Angaben so lange nicht für die Empfänger sichtbar, wie nicht zugleich die TraceHistory-Datenbank weiter gegeben wird (siehe unten: TraceHistory Database).

Abbildung 5.41: TraceHistory: Memo

5.12.5 TraceHistory: History Database Die TraceHistory-Datenbank ist abgelegt in den Datenbank-Tabellen mit Dateinamen TM.DB.RN*.* und TM.DB.RF*.*, zunächst abgelegt im Systemverzeichnis .\TraceMagic\data\database. Solange die History-Datenbank nicht aus dem Systemverzeichnis wegverlagert wird, enthält sie tatsächlich alle History-Einträge. Nun kann es gewollt sein, dass eben nicht alle Analyse-Vorgänge in derselben History-Datenbank abgespeichert werden oder anders herum betrachtet: Es kann gewollt sein, für alle Analysen innerhalb eines Projekts (beispielsweise bezogen auf getrennte Kunden) jeweils eine eigene History-Datenbank zu führen.

160

>>> NEW TECH

TraceEvents/EventFilter

Abbildung 5.42: TraceHistory: History Database

In diesem Falle wird über den Button mit der DB-Beschriftung ein beliebiges anderes (und sinnigerweise leeres) Festplatten-Verzeichnis ausgewählt; in dieses Verzeichnis legt TraceMagic automatisch eine neue TraceHistory-Datenbank, diese ist zunächst leer und nimmt ab dem Zeitpunkt ihrer Erzeugung alle weiteren History-Einträge auf, bis ggf. die History-Datenbank wieder gewechselt wird. Ein Wechsel zu einer beliebigen anderen History-Datenbank erfolgt über den Verzeichnisbrowser links; das Laden der mit Installation im Systemverzeichnis database liegenden History-Datenbank wird automatisch mit Mausklick auf den Button mit dem TraceMagic-Icon vorgenommen.

5.13 TraceEvents/EventFilter Sowohl das TraceHistory-Fenster wie auch das ReportViewer-Fenster bieten den Aufruf der Funktion TRACEEVENTS/EVENTFILTER an. Diese Funktion erlaubt, aus allen Dateien mit dem Namen TM.HIT.FRAMES.*.LOG.TXT gezielt bestimmte Einträge herauszufiltern. Der Vorgang ähnelt dem unter Unix bekannten Kommando »grep«. Es können vier verschiedene Textmerkmale angewählt und aktiviert werden; sie können mit der logischen Verknüpfung AND/OR verwendet werden.

>>> NEW TECH

161

Kapitel 5 • TraceMagic

Mit dem Mechanismus der EventFilter können völlig unkompliziert selbst aus einer Vielzahl von Event-Log-Dateien alle Ereignisnachweise herausgefiltert werden, die mit einem bestimmten Verdacht in Verbindung stehen. Diese nachträglichen Text- bzw. Ereignisfilter sind in vielen Fällen weitaus effizienter als Paketfilter im LAN-Analyzer oder TraceFilter während der eigentlichen TraceMagic-Analyse.

Abbildung 5.43: EventFilter: Vor dem Start eines Filtervorgangs; gesucht werden im Event-Log mit UNDVerknüpfung alle Einträge mit der IP-Adresse 149.223.x.x sowie mit allen WINSVorgängen. Im Ergebnis nimmt der Text-Filter als Treffer alle Zeilen mit, welche die TextBestandteile »149.223« und »WINS« enthält.

Abbildung 5.44: EventFilter: Das Ergebnis, eine gefilterte Event-Log-Datei. Der Datei-Name weist auf den verwendeten Filter hin.

162

>>> NEW TECH

TraceEvents/EventFilter

Abbildung 5.45: EventFilter: Auflistung aller Event-Log-Dateien (gefiltert und ungefiltert)

>>> NEW TECH

163

Teil II LAN-Analyse in den OSI-Schichten 1 bis 7

Kapitel 6 Kapitel 7 Kapitel 8 Kapitel 9 Kapitel 10 Kapitel 11

OSI-Schichten 1 und 2 TCP/IP-Grundlagen OSI-Schichten 3 und 4: TCP/IP OSI-Schichten 5 und 7: Namensdienste OSI-Schicht 7: Anwendungen TCP- und Applikations-Analyse

167 223 327 359 393 403

Kapitel 6 OSI-Schichten 1 und 2 Dieses Kapitel bespricht Eigenheiten und Fehler, die sich den OSI-Schichten 1 (Physical Layer) und 2 (Data Link Layer) zuordnen lassen oder mit diesen beiden Schichten eng verbunden sind. Die hier beschriebenen Fehler und Befunde sind überwiegend vom Verfasser in den Jahren 2000-2002 diagnostiziert worden. Sie sind interessant, insofern sie den allgemein typischen Fehlern der OSISchichten 1 und 2 auf den ersten Blick nicht entsprechen wollen. Wer noch zu Beginn oder Mitte der 90-er Jahre mit Ethernet-Koax-Kabeln gearbeitet hat, verbindet mit dem Thema »Fehler in der Netzwerk-Physik« oder »Fehler auf Data Link Layer« eher Ethernet-Kollisionen, Kurzschluss oder Knick-Defekte des Koax-Kabels oder Beacon-Ereignisse im Token-Ring. Da diese »klassischen« Fehler heute in der Tat – und in erfreulicher Weise – eher selten geworden sind, nimmt man allgemein an, der Physical Layer wäre heutzutage ein eher langweiliges Feld der Netzwerk-Analyse. Richtig an dieser Annahme sind dreierlei Umstände: ■ ■ ■

Erstens sind Verkabelungen mit Twisted-Pair-Kabeln angenehm robust und zuverlässig. Zweitens sind LANs, die durch Switches segmentiert sind, nicht oder nur selten anfällig gegenüber Fehlern der Netzwerk-Physik. Drittens benötigt man meistens zur Diagnose von Fehlern in der LANPhysik noch nicht einmal einen LAN-Analyzer, da sich die Fehler in aller Regel von selbst erklären.

Gerade deswegen aber sind die folgenden Beispiele interessant, weil sie sich diesem allgemeinen Muster entziehen. Wie immer steckt der Teufel im Detail und wie so oft hängt der Nachweis oftmals am eingesetzten Werkzeug.

6.1 Messtechnik und Analyse auf den OSI-Schichten 1 und 2 Zunächst sollen die Veränderungen der letzten Jahre beleuchtet werden, die sich in der Messtechnik ergeben haben, sofern sie mit den OSI-Schichten 1 und 2 zu tun haben. Daher die Frage: »Was ist neu?«

>>> NEW TECH

167

Kapitel 6 • OSI-Schichten 1 und 2

6.1.1

Was ist neu?

Zunächst einmal scheint es so, als habe sich seit dem Jahr 2000 nicht so viel ereignet, was Messtechnik auf dem Physical-Layer und Data Link Layer anbetrifft. Ein paar Bemerkungen jedoch müssen mit Blick auf Gigabit-Messungen gemacht werden, aber auch ein paar Worte des Abschieds mit Blick auf FDDI und ATM im LAN sollen gesprochen werden. Ansonsten bleibt zu sagen: Auch wenn Messungen des Verfassers seltener wurden, bei denen defekte Netzwerk-Hardware ursächlich beteiligt war, ist es dennoch nicht so, als träten hier Fehler nicht mehr auf. Neu ist, dass einige der wirklich hässlichen Fehler, die der Verfasser in den Jahren 2001 und 2002 nachweisen konnte, von angeblich marktführenden LANAnalyzern nicht erkannt bzw. vollkommen falsch gedeutet wurden. Insofern also haben wir es hier in der Tat mit ein paar neuen Effekten zu tun – oder doch wenigstens mit neuen Methoden, sie nachzuweisen.

6.1.2

Abschied von ATM, FDDI und Token-Ring im Campus-LAN

Noch im Jahr 2000 war nicht wenigen Kunden unklar, ob und wann sie von Token-Ring und FDDI Abschied nehmen würden. Diese Unklarheit ist heute weitgehend beseitigt: Diese alten Techniken sind inzwischen fast überall abgebaut. ATM in LAN-Backbone ist ebenfalls, so weit es der Verfasser beobachten konnte, bei vielen Anwendern zügig durch Gigabit-Ethernet ersetzt worden. Aus Sicht des Verfassers waren diese Entscheidungen richtig, weil in ATMBackbones praktisch aller großen Hersteller immer wieder hässliche Fehler nachgewiesen werden konnten, von denen die Techniker der Hersteller noch nicht einmal selber wussten, dass es sie überhaupt geben könnte. Wer immer an die Regel »keep it simple« glaubt, tut gut daran, das doch deutlich einfachere Ethernet-Konzept an die Stelle des komplexeren ATMs treten zu lassen. Zu FDDI bleibt zu sagen, dass die hohe Verfügbarkeit des Doppel-Ringes zwar immer gern gesehen wurde, dass aber die heutigen Redundanz-Möglichkeiten im Ethernet allgemein als ausreichend anerkannt werden. Auch muss festgestellt werden, dass der Verfasser in den letzten zwei, drei Jahren einige FDDIMessungen durchgeführt hat, bei denen die Kunden darüber klagten, seitens der Hersteller keinen als ausreichend empfundenen Support (mehr) zu erhalten. Unter solchen Bedingungen versteht sich, warum Kunden dann doch schnell zu Ethernet wechseln. Der Abgesang sei beschlossen mit dem Hinweis, dass der Verfasser mit TokenRing einen seiner Lieblinge verloren hat: Die Logik dieser Technik hat einfach Spaß gemacht, denn sie war durchdacht, stringent, elegant ..., zwar auch dinosaurierhaft schwerfällig, aber wer liebt nicht seine Dinos! Andererseits ist der Verlust verwindbar, denn es gibt neue Lieblinge und die sind nicht schlechter.

168

>>> NEW TECH

Messtechnik und Analyse auf den OSI-Schichten 1 und 2

(Sagen wir mal: alles, was Microsoft Windows so auf der Netzwerk-Leitung macht, entschädigt doch oft für den Verlust alter Lieblinge wie etwa TokenRing!)

6.1.3

Gigabit-Ethernet: Messungen unter Gigabit-Bedingungen

Noch in 2000 waren Messungen in Gigabit-Backbones über die Mirror-Ports der Switches als deutlich problematisch anzusehen, da die Paketverlustrate meistens unerfreulich hoch war. Inzwischen gibt es einige Fabrikate, die sich in der Praxis des Verfassers als erfreulich leistungsfähig und zuverlässig erwiesen haben. Als Beispiel sei die Familie der Cisco 6000 er Switches genannt: Das Ausspiegeln von Rx/Tx auf dem Gigabit-Mirror-Port stellt kein nennenswertes Problem mehr dar. Im Herbst 2002 führte der Verfasser eine Messung durch, bei der über Stunden im Schnitt alle zehn Sekunden 32 Megabyte Messdaten auf die Festplatte des Analyzers geschrieben wurden – und das, wie die spätere Auswertung ergab, praktisch verlustfrei: Die Paketverlustrate lag weit unter einem Promille des Gesamtverkehrs. In diesem Zusammenhang sei selbstverständlich erwähnt, dass eine solche Leistung auch mit der Performance des LAN-Analyzers zusammenhängt. In diesem Falle arbeitete ein Messrechner (www.staccer.de) mit einem 2-GHz-Prozessor, 800 MHz RAMBus, schneller RAID-0-Doppel-Festplatte, vorzüglicher Gigabit-Adapter-Karte (SysConnect) und dem wirklich beachtlich guten EtherPeek NX als Analyzer-Software. Doch zurück zur Hardware der Gigabit-Switches: Gemessen an der Leistungskraft von Switches wie denen der Cisco 6000-er Serie mutet es nahezu schon anachronistisch an, wenn im Jahr 2002 immer noch Anbieter versuchen, Switches zu verkaufen, die noch nicht einmal Rx/Tx gemeinsam auf dem Mirror-Port ausgeben können! Jeder Kunde muss ernstlich prüfen, ob er Switches kaufen will, die den messtechnischen Zugang massiv erschweren, wenn nicht gar unmöglich machen. Angesichts des Umstandes, dass die Anforderungen an die Verfügbarkeit der Daten und Dienste nahezu überall nahe bei 100% liegen, dürfte (besser: sollte!) es eine Selbstverständlichkeit sein, dass der messtechnische Zugang eine Pflichtübung ist. Wer hier Geld spart, zahlt fast immer hinterher drauf. Dabei geht es nicht um den Verdacht, dass später einmal diese Switches selber defekt sein könnten – es geht um den Standardfall simpler LAN-Analyse, wenn es sich um das Aufdecken beliebiger Ereignisse und Fehler in der Datenkommunikation handelt. Es ist ersichtlich zu umständlich, an vier oder zehn Servern getrennt Messpunkte anzusetzen: Es ist einfacher, im Core-Backbone einen Datenstrom abzugreifen, an dem die Daten aller Server gemeinsam vorüberkommen (immer die

>>> NEW TECH

169

Kapitel 6 • OSI-Schichten 1 und 2

Voraussetzung mitgedacht, dass eine leistungsstarke Software zur späteren und automatischen Auswertung solch großer Datenmassen vorhanden ist). In gewisser Weise spielt in diese Diskussion mit hinein, welche Fähigkeiten die Core-Switches zusätzlich innerhalb des klassischen Bereichs von NetzwerkManagement bieten: SNMP, RMON, SMON, SFLOW. Diese Methoden stellen zwar im eigentlichen Sinne mehr Statistik zur Verfügung und weniger Analyse, aber sie bieten wichtige Online-Fähigkeiten zum schnellen Vor-Checking: Fähigkeiten, die ihrerseits wiederum geeignet sind, wichtige Vorentscheidungen hinsichtlich etwaiger Messungen mit dem LANAnalyzer zu ermöglichen. Insbesondere Fehler auf dem Physical-Layer (was hier oft bedeutet: Fehler irgend eines der beteiligten Core-Switches) sind oft schon über die Statistiken der jeweils gegenüber liegenden Nachbar-Switches gut eingrenzbar. Der Verfasser dieser Zeilen kann es bis heute kaum fassen, dass er noch im Jahr 2002 Kunden antraf, die keinen Zugriff auf diese Statistiken hatten: entweder, weil die Software hierzu nie installiert wurde oder weil diese Software zu kompliziert sei (sagen manche Kunden) oder weil die Switches unter der Herrschaft von Lieferanten oder Dienstleistern standen, die eifersüchtig auf ihre Zugriffsberechtigungen schielen, aber keine Dritten zugreifen lassen (und den Kunden schon gar nicht). Man soll es kaum glauben, aber dann und wann finden sich solche Zustände immer noch. Gut, aber das sind alte Zustände. Zurück also zu der Frage: »What’s new?« Neu sind verschiedene Methoden, unter Gigabit-Bedingungen an den LANVerkehr heran zu kommen. Der Mirror-Port bietet sich zwar grundsätzlich an, weil diese Arbeitsweise unkompliziert ist, aber sie scheidet manches Mal aus: Sei es, dass kein Port mehr frei ist, sei es, dass der Switch hierfür keine Unterstützung bietet, sei es, weil die Leistung des Switches zu weit vermindert wird, wenn der Mirror-Port über längere Dauer (Stunden) aktiv bleibt. Hier stellt sich die Frage, ob sich der Einsatz eines Media-Splitters anbieten könnte.

6.1.4

Media-Splitter (TAP) statt Mirror-Port

Ein Media-Splitter wird als kleine Box in die Glasfaser-Doppelader eingeschleift und die beiden Rx/Tx-Leitungen werden jeweils getrennt herausgespiegelt (passiv). Die Vorteile eines Media-Splitters sind schnell verständlich: ■ ■ ■

170

Der Switch wird in seiner Leistungskraft nicht beeinträchtigt. Etwaige Switch-Fehler können eindeutig erkannt und zugeordnet werden. Etwaige Kabelfehler können besser zugeordnet werden.

>>> NEW TECH

Messtechnik und Analyse auf den OSI-Schichten 1 und 2

■

Der Zugriff mit dem LAN-Analyzer ist ohne Schaltung des Mirror-Ports möglich und somit auch ohne Anwesenheit eines Berechtigten, der mit Passwort Zugriff auf die Konsole des Switches hat (sei es per Telnet, sei es per HTML).

Trotzdem gibt es auch Nachteile, die wohl kalkuliert werden müssen: ■

■

■

■

Media-Splitter sind teuer. Da sie vom Konzept her so gedacht sind, dass sie dauerhaft in Inter-Switch-Connections oder Switch-Server-Anbindungen eingebaut werden (um jederzeit messtechnischen Zugriff zu gestatten, aber auch, um die bei Einbau notwendige Unterbrechung zu vermeiden), stellen sie insofern zunächst einen erkennbaren Kostenblock dar, als für viele Server eben auch viele Media-Splitter angeschafft werden müssten. Media-Splitter geben die Daten aus Rx- und Tx-Leitung getrennt aus. Ein Standard-Analyzer jedoch, der über eine Standard-Adapter-Karte arbeitet, kann damit entweder nur die Rx-Daten oder die Tx-Daten aufnehmen. Damit aber wäre die Messung in den meisten Fällen schlicht wertlos. Dieses Manko lässt sich nur mit zusätzlichem Aufwand umgehen: Eine Variante ist der Einsatz eines Dual-Receive-Port-Adapters, der die beiden Rx/Tx-Ausgänge des Media-Splitters aufnehmen kann – zu dem Zweck, beide Datenströme zu einem zeit-synchronisierten Rx/Tx-Strom zu vereinigen. Diese Dual-Receive-Port-Adapter sind teuer (ca. 10.000 US Dollar können fällig werden) und somit nicht für den täglichen Einsatz gedacht, zumal auch die Analyzer-Software diesen Spezial-Adapter ansprechen können muss. Network Instruments (Observer) bietet einen solchen Adapter an. Eine andere Variante wäre, zwei normale Gigabit-Adapter im Analyzer-PC zu haben. Die darüber laufende Analyzer-Software synchronisiert gemäß Zeitstempel die Rx/Tx-Datenströme des Media-Splitters (die für die beiden Gigabit-Adapter einfach nur als Rx angesehen werden). Eine Lösung dieser Art scheint sich bei WildPackets (EtherPeek) mittelfristig anzukündigen.

Die »gute Nachricht« lautet also: Es gibt die nötigen technischen Lösungen, um Gigabit-Messungen unter verschiedenen Bedingungen zuverlässig durchführen zu können. Die »schlechte Nachricht« dagegen lautet: Das kostet nicht wenig Geld.

6.1.5

Geeignete Capture Engines für Gigabit-Messungen

Ein wirklich leistungsfähiger Gigabit-Messrechner muss, wenn er denn Sinn ergeben soll, mit einem Preis deutlich oberhalb 20.000 EUR veranschlagt werden. Es muss in diesem Zusammenhang daran erinnert werden, dass so genannte Hardware-Analyzer aus Sicht des Verfassers ihre Zukunft schon hinter sich haben und weitgehend überflüssig geworden sind. Unter Hardware-Analyzern werden Maschinen verstanden, die nicht über (mehr oder weniger) »normale« LAN-Adapter arbeiten und sich insofern auf die Entwicklung der Software

>>> NEW TECH

171

Kapitel 6 • OSI-Schichten 1 und 2

beschränken, sondern die auf Spezial-Adaptern Prozessoren (ASICs) sitzen haben, die bereits online und in Echtzeit Analyse-Funktionen ausführen können. Die Erfahrung des Verfassers ist: Die Entwicklung ist zu schwerfällig und hinkt den Erfordernissen ständig hinterher; bei technischen Mängeln dauert es in vielen Fällen zu lang, bis Besserung erreicht oder Ersatz beschafft ist; das Preis-Leistungs-Verhältnis ist nicht vertretbar. Die heute verfügbaren Software-Lösungen sind von so großer Leistungsfähigkeit und im Preis-Leistungs-Verhältnis so gut, dass die Hardware-Analyzer kaum noch sinnvoll vermittelbar sind. In den Eingangskapiteln dieses Buches wurde hierüber ausführlich berichtet.

6.1.6

TcpDump auf dem Gigabit-Server

Weiterhin sei an die Möglichkeit erinnert, bei Servern, die mit Gigabit angeschlossen sind, von vornherein auf einen LAN-Analyzer zu verzichten und stattdessen auf dem Server selber das Programm TcpDump mitlaufen zu lassen. Das Ergebnis ist ein Capture-Trace, der mit dem eines extern angeschlossenen LAN-Analyzers identisch ist. Per FTP vom Server herunterkopiert kann dieser Trace später beliebig ausgewertet werden. Dies gilt unter der (nicht ganz unproblematischen) Voraussetzung, dass der Server über hinreichend Prozessorkraft verfügt, um den TcpDump sauber zu bedienen, ohne dass die restliche Server-Leistung heruntergeht, gilt: Diese Methode ist einfach, effizient und vor allem hervorragend geeignet, um Verdachtsmessungen mitlaufen zu lassen. Verdachtsmessung, das heißt eine Messung, die lediglich auf vagen Verdacht hin gestartet wird, etwa wenn ein Anwender nebulös und vage äußert, bei bestimmten Benutzeraktionen am Bildschirm würde ein Server (oder eine Applikation) auf diese oder jene unerfreuliche Weise reagieren. In solchen Fällen ist es wesentlich unkomplizierter, über einen simplen Script-Befehl TcpDump zu starten, als den teuren LAN-Analysten in Gang zu setzen. Es soll nicht verschwiegen werden, dass der TcpDump-Weg zurzeit bei realistischer Betrachtung Unix-Servern vorbehalten ist. Für Windows-Server sind ähnliche Methoden zwar theoretisch verfügbar, aber praktisch nicht akzeptiert (oder auch nicht sinnvoll). Für TcpDump-Anfänger sei ein Syntax-Hinweis gegeben, der sich bisher als sinnvoll heraus gestellt hat: tcpdump -w file -s framelength -c filelength

6.1.7

Load Balancing

Aus der Welt der Internetprovider haben inzwischen die so genannten Load Balancer ihren Einzug in die Technik des Campus-LANs gefunden. Vor großen Server-Farmen werden Switches bzw. Router eingesetzt, die den eingehenden 172

>>> NEW TECH

Messtechnik und Analyse auf den OSI-Schichten 1 und 2

Datenverkehr auf verschiedene Server verteilen (und umgekehrt zurück), um die Server einerseits gleichmäßig auszulasten und um andererseits jeden einzelnen Server vor Überlast zu schützen. Szenerie 1: Load Balancer, die auf Layer 2 arbeiten und mit redundanter Switch-Struktur kombiniert sind, können je nach Design des LANs dazu führen, dass im Backbone ein Kreisverkehr entsteht: Die Daten der Clients zum Server fließen dann gewissermaßen links herum (über den ersten von zwei sich gegenseitig redundant absichernden Switches), der Rückverkehr der Server rechts herum (über den jeweils zweiten Switch). Messungen in einem solchen Umfeld sind nur noch dann sinnvoll möglich, wenn die getrennten Datenströme an einem vorbereiteten Messpunkt wieder zusammengeführt werden. Das kann beispielsweise so geschehen: An jedem der beiden Switches (jeder leitet den Verkehr nur in jeweils einer Richtung weiter) wird ein Mirror-Port gelegt; die Daten dieses Mirror-Ports beider Switches werden auf einen dritten Switch gelegt; dort werden die eingehenden Daten der beiden ersten Switches gemeinsam auf einen dritten Mirror-Port gelegt, der dann wiederum einen LAN-Analyzer bedient. Voraussetzung ist natürlich, dass man einen dritten Switch frei zur Verfügung hat, der dann auch wiederum in der Lage ist, mehrere Ports auf dem Mirror-Port auszuspiegeln. Szenerie 2: Werden Router als Load Balancer genommen, kann außer dem normalen Routing auch mit NAT gearbeitet werden (Network Address Translation), einem Austauschen der IP-Adressen. Dies geschieht in der Regel aus Sicherheitsgründen, um außen liegenden Clients keinen Aufschluss über die tatsächlichen IPAdressen der Server zu geben. In einem solchen Fall können Messungen (genauer: kann das Auswerten von Messdaten) erschwert werden, weil links und rechts vom Load Balancer die IPAdressen nicht übereinstimmen. In diesem Falle ist in gewisser Weise die letzte Rettung, wenn wenigstens die TCP-Port-Kennungen den NAT-Router unverändert durchlaufen. Anhand der TCP-Ports lassen sich dann die Dialoge zweifelsfrei erkennen. Fallen die Port-Nummern weg, bleiben (nur) noch die TCP-Offset-Kennungen (TCP Sequence Number), mit denen ein Absender die Datenposition im Sendestrom kennzeichnet. Im Falle unveränderter Port-Kennungen lassen sich mit TraceMagic (siehe beiliegende CD-ROM) alle TCP-Pakete aus den Originalmessdaten herausfiltern, die beiderseits des NAT-Routers bzw. Load Balancers dieselben Port-Kennungen enthalten. Danach ist ein Vergleich der TCP/IP-Daten »links« und »rechts« vom NAT-Router verhältnismäßig leicht möglich. Dieses Szenario ist natürlich auch ohne Load Balancer zu haben; nicht selten werden NAT-Router an der WAN-Schnittstelle eingesetzt. >>> NEW TECH

173

Kapitel 6 • OSI-Schichten 1 und 2

Im Kapitel der TCP/IP-Praxisbeispiele wird ein Fall dargestellt, der Fehler rund um einen Load Balancer mit NAT-Routing zum Gegenstand hat.

6.2 Beispiele für Fehler und ihre Diagnose durch LAN-Analyse Die folgenden Beispiele entstammen sämtlich der Praxis des Verfassers. Die Daten sind anonymisiert, soweit nötig und möglich, um Rückschlüsse auf die echten Zusammenhänge nicht sichtbar werden zu lassen.

6.2.1

Erdungsfehler: Switch defekt, Frames defekt

Quelle: Stuttgart, 2000.

Von dieser Messung liegen leider keine Capture-Daten mehr vor. Wir werden uns also mit dieser kurzen, aber sehr lehrreichen Anekdote begnügen müssen. Der Verfasser war eingeladen, bei einem Bauplanungsunternehmen ein Seminar zur LAN-Analyse zu geben. Der Kunde sah sich hierzu veranlasst, da er einige unerklärliche Störungen in seinem Netzwerk hatte – sporadisch zwar, über den Verlauf der Tage und Wochen hinweg aber doch mit unerfreulicher Regelmäßigkeit. Als der Verfasser am Morgen des ersten Tages in dem mehrstöckigen, großen Betonbau eintraf, meldete er sich beim Pförtner, dieser verständigte den zuständigen Ansprechpartner aus der EDV, jener kam dann zum Empfang und führte den Verfasser zum Fahrstuhl mit der Bemerkung, sie führen bzw. gingen jetzt zum Server- und Verteilerraum. Sodann drückte der EDV-Mann im Fahrstuhl den Knopf für eines der Obergeschosse. Das löste seitens des Verfassers sofort Erstaunen aus: Liegen Rechenzentren nicht für gewöhnlich im Tiefgeschoss? Sei das denn hier nicht genau so? Nein, kam die Erwiderung, da die Zahl der Server nicht allzu groß sei, habe man einen der Räume im Obergeschoss belegt. Wieder Rückfrage: Wie denn die Erdung der Schaltschränke und Anlagen sichergestellt würde? Ob der im Obergeschoss liegende Server-Raum denn eine eigene, separate Erdungsleitung ins Fundament bzw. ins darunter liegende Erdreich hätte? Hierauf zeigte sich der EDV-Mann erstaunt und meinte, darüber hätte er noch nicht nachgedacht und sonst wohl auch niemand. Na, gut, dachte sich der Verfasser, fremde Länder, fremde Sitten. Vielleicht funktioniert im Ländle die Elektrik doch anders als im Rest der Republik. ... Im Zuge des Seminars wurden LAN-Messungen an verschiedenen Punkten des Netzwerkes durchgeführt. Es zeigte sich, dass es höchst sporadisch große Mengen zerstörter Ethernet-Frames gab, stoßartig und in teilweise unerfreulichem Umfang.

174

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Es lag eine CAT-5-Verkabelung vor, die zentral im Verteilerraum an den Switches eines marktführenden Herstellers aufgeschlossen war. Über die Verlegung der Messpunkte, aber auch über testweises Zwischenschalten von Ethernet-Repeatern an geeigneten Punkten der Ethernet-Segmente ergab sich nach und nach, dass die Verfälschungen der Ethernet-Frames zweifelsfrei von den zentralen Switches ausgingen. Die Messdaten zeigten, dass es sich unmöglich um Kollisionsereignisse oder Kabeldefekte (Knick, Kurzschluss) handeln konnte (siehe hierzu die einschlägigen Erklärungen im nachfolgenden Beispiel), da die defekten Ethernet-Frames nicht etwa die für Kollisionen typischen Längen bis maximal 64 Oktette aufwiesen, sondern auch in längeren Frames auftraten (bis 1.518 Oktette Länge). Außerdem zeigten die Verfälschungen nicht die für Kollisionen typischen Merkmale. Auf einmal war sie wieder da, die Frage vom ersten Morgen: Wie stehe es denn eigentlich mit der Erdung der 19-Zoll-Schränke? Dieser Frage wurde nunmehr nachgegangen: Aus dem Scherz war Ernst geworden. Es zeigte sich am Ende das folgende, erschreckende Bild: Die 19-Zoll-Schränke – und damit auch die Chassis der Switches – waren über die normalen Steckdosen der Hauselektrik »geerdet«. Niemand hatte daran gedacht, dass dies nicht ausreichen könnte. Weiterhin rückte nun die Architektur des Hauses in den Blick: ■

■

■

■

Einen separaten Erdungskanal ins Erdreich gab es nicht. Das kleine Rechenzentrum im Obergeschoss hatte gar keine Chance, eine eigene Erdung zu erhalten. Der große Betonriegel des vielleicht sechs Stockwerke hohen Neubaus (man bedenke: der Kunde war eine Bauplanungsunternehmung!) war etwa 100 bis 200 Meter lang. Das eine Ende des Gebäudes lag eher trocken an der Hauptverkehrsstraße, das andere Ende eher feucht zum Wiesengrund hin. Zur Straße hin standen wenig Bäume, zum Wiesengrund hin immer mehr. Dieser Aufbau kann zu folgenden Wirkungen führen: Bei entsprechender Wetterlage bilden sich in der Umgebung des Gebäudes unterschiedliche elektrische Umgebungsbedingungen aus; insbesondere die zum feuchten Wiesengrund hin stehenden Bäume bauen ein anderes elektrisches Umfeld auf, als zum eher trockenen Straßenende hin herrschen. Da die Verkabelung des Hauses auf elektrische Umgebungsbedingungen induktiv reagieren kann, kann es zwischen den verschiedenen Enden des Gebäudes zu Unterschieden im elektrischen Potenzial kommen; dies wiederum kann zu Ausgleichsströmen und spontanen Entladungen führen. In jedem Fall ist die Erdung der herkömmlichen Hauselektrik, sofern sie durchgängig und einheitlich ist, nicht vollständig gewährleistet. Dies führte gegenüber dem Kunden zur Frage: Gibt es für die verschiedenen Gebäude-Abschnitte wenigstens getrennte elektrische Strom- und Erdungskreise? – Das konnte zunächst gar nicht beantwortet werden und es musste nachgefragt werden. Die Antwort lautete: Nein, das gesamte Gebäude (in

>>> NEW TECH

175

Kapitel 6 • OSI-Schichten 1 und 2

■

seiner gesamten Längserstreckung) sei mit einer durchgehenden, einheitlichen elektrischen Verkabelung und Erdung versorgt. (Die Frage nach getrennten Brandabschnitten wagt man da gar nicht mehr zu stellen. ...) Somit zeichnete sich ab: Die 19-Zoll-Schränke im Server-Raum waren tatsächlich nicht vorschriftsmäßig geerdet, sondern litten unter Störeinflüssen, die zu elektrischen Entladungen vom Switch-Chassis auf die CAT-5-Kabel führten.

Erst einmal bis dahin gekommen, beichtete der Kunde einigermaßen bedrückt Folgendes: Na, ja, man habe sich ja bis dahin nichts dabei gedacht, aber man hätte nun schon den dritten Switch des Herstellers im Herzen des 19-Zoll-Schrankes. Man habe bislang halt immer gedacht, die Switches seien defekt gewesen. Jedes Mal habe ein neuer Switch erst über Wochen sauber gearbeitet und dann seien die Aussetzer bzw. Störungen immer häufiger geworden. So erklärte sich am Ende von selbst, dass die Switches, je länger sie dieser Umgebung ausgesetzt waren, umso mehr litten und Defekte davontrugen. In jedem Falle führten die elektrischen Entladungen über die CAT-5-Kabel zu den diagnostizierten Verfälschungen der Ethernet-Frames. In gewisser Weise arbeiteten die CAT-5-Kabel in diesem Szenario als Erdungskabel und die Ableitung von Kriechströmen oder Entladungen konnte im schlechtesten Falle bis zu den angeschlossenen Ethernet-Adaptern der Endgeräte führen – die wiederum an der Hauserdung angeschlossen waren, ein wahrer Alptraum für den Elektriker. Da kurzfristig kein getrennter Erdungskanal ins Erdreich unter dem Fundament gelegt werden konnte, sann der Kunde am Ende darüber nach, vielleicht durch Einsatz von USVs Abhilfe zu schaffen. In jedem Falle gaben die EDV-Leute den Kollegen aus der Bauplanung Nachricht, dass bei Planung einer Architektur auf gewisse Belange der EDV bzw. der LAN-Technik Rücksicht genommen werden sollte. ..

HINWEIS Fazit: Fehler in der LAN-Physik müssen nicht wirklich ursächlich in den Komponenten der Netzwerk-Technik begründet sein. Fehler in den elektrischen Umgebungsbedingungen können die aktiven Komponenten zu Opfern machen, die dann ihrerseits Reaktion zeigen.

Die Lehre hieraus ist: Wenn mit den LAN-Analyzern Verfälschungen oder Verstümmelungen von Ethernet-Frames nachgewiesen werden, muss mit einem durchdachten Versuchsaufbau der Nachweis erbracht werden, ob Fehler der aktiven NetzwerkKomponenten ursächlich beteiligt sind oder eben nicht.

176

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Diese Nachweise können mal einfacher, mal schwieriger sein. Im Zweifel sollte der LAN-Analyst die Hinzuziehung eines Elektrikers empfehlen, der die Erdung und die allgemeinen elektrischen Umgebungsbedingungen sauber durchmisst. Der Verfasser selber tut dies nicht (es bedürfte auch einer geeigneten Ausbildung), hatte bislang aber auch immer die Möglichkeit, über einen geeigneten Versuchsaufbau bei der LAN-Messung zum Ergebnis zu kommen. Dieses Beispiel hier aufzuführen war wichtig, weil es auf ein allgemein unterschätztes Problem verweist und weil es die Komplexität des nachfolgenden Beispiels greifbarer macht. Solange man die Lösung zu einem aktuell gestellten Problem noch nicht kennt, solange man sich also noch im gedanklichen Prozess der Diagnose befindet, solange bewegt man sich in einem Puzzle, in dem alle denkbaren Möglichkeiten berücksichtigt und nach und nach ausgeschlossen werden wollen. Die Abgrenzung zwischen endogenen Fehlern (die gewissermaßen »von innen heraus« kommen) und exogenen Fehlern (die »von außen« in Form von Störeinflüssen einwirken) ist nicht immer einfach. Im folgenden Beispiel wird deutlich, welche Umwege die Überlegungen manches Mal gehen müssen, um zum Ergebnis zu kommen.

6.2.2

Defekte Ethernet-Frames (1): Switch-Fehler

Quelle: Calw (Schwarzwald), 2001.

Die Anwender klagten über spontan lange Antwortzeiten (»Das Netzwerk ist langsam«) sowie über ebenfalls spontane Sitzungsabbrüche. Dem Kunden war bereits zuvor bei eigenen Messungen aufgefallen, dass es zeitweilig Ethernet-Runts auf den Leitungen gab. »Runts« sind, wörtlich übersetzt, »Krüppel«: Das sind in der Ethernet-Sprache kleine Frame-Fragmente, in der Regel mit einer Länge zwischen 12–14 Oktette und in aller Regel sind Runts die Folge von Kollisionen. So viel war dem Kunden bekannt. Was sich der Kunde nicht erklären konnte: Wie können sich Ethernet-Kollisionen ereignen, wenn doch das gesamte Campus-LAN über Switches arbeitet, nicht über Repeater (Hubs)? Es gab den vagen Verdacht, dass die Switches im Core-Backbone defekt sein könnten. Der Hersteller (ein marktführender IT-Ausrüster aus den USA) hatte zwar bereits eigene Messungen durchgeführt, hatte aber auch jeden Zusammenhang der Ereignisse mit seinen eigenen Switches verneint. Der Kunde jedoch konnte nach einigen Wochen keine andere Erklärung mehr finden, als dass genau diese Switches an den Fehlern beteiligt sein müssten, da sich die Ereignisse nicht mehr anders erklären ließen – allem Widerspruch des Herstellers zum Trotz.

>>> NEW TECH

177

Kapitel 6 • OSI-Schichten 1 und 2

Die Aufgabe bestand also darin, Folgendes herauszufinden: ■ ■

Was geschah, wenn die spontan auftretenden Fehler zu langen Antwortzeiten und ggf. sogar Sitzungsabbrüchen führten? Wie ließ sich nachweisen, ob ein Zusammenhang mit den Core-Switches im Backbone bestand (oder eben nicht)?

Zunächst einmal musste die Messung stattfinden. Hierzu wurden zwei Messrechner an verschiedenen Punkten des LANs angeschlossen: ■ ■

Ein Messrechner in einer Client-Workgroup Ein Messrechner vor einem Server; hierzu wurde ein Ethernet-Repeater (Hub) zwischen Switch und Server geschaltet.

Um nach den ersten Befunden einen möglichen Einfluss des Repeaters auszuschließen, wurde die Messung mit einem anderen Repeater eines anderen Herstellers wiederholt; da sich die Ergebnisse glichen, konnte somit als glaubwürdig ausgeschlossen gelten, dass der Versuchsaufbau und -ablauf durch die Repeater beeinflusst worden wäre. Aber auch die spezielle Charakteristik der Abläufe und Befunde ließ eine Einwirkung der Repeater ausschließen. Nun kommen wir aber zum Hergang und zur Deutung der Daten: Es stellte sich heraus, dass in der Tat kurze Ethernet-Runts spontan auf der Leitung waren. Sie traten sehr zufällig verteilt auf. Daher waren zum sicheren Nachweis Messungen über den gesamten Tagesverlauf notwendig. Eine Betrachtung der Daten lieferte folgende Erkenntnisse: ■ ■ ■

Die Ethernet-Runts enthalten vermeintliche MAC-Adressen wie folgt: MAC = D0D0D0D0D0D0 und MAC = 434343434343. Die Ethernet-Runts sind fast alle zwölf Oktette lang, nur wenige sind 13 Oktette lang. Jedoch zeigen sich zwischendurch IP-Pakete, die scheinbar »normal« sind, und doch mit den Runts in Zusammenhang stehen. Hier schien letztlich der Schlüssel zur Lösung zu liegen.

Die Abbildungen zeigen zwei Ereignis-Logs von TraceMagic zu den verschiedenen Fehlertypen. Zunächst ist die Deutung der Frame-Krüppel von größter Bedeutung. Denn es stellt sich heraus, dass es sich eben nicht um typische Kollisionsreste handelt, sondern um künstlich erzeugte Frame-Schnipsel. Dies ergibt sich aus folgenden Erwägungen und Charakteristika: ■

178

Ethernet-Runts treten in ihrer klassischen Form nur in Repeater-Segmenten auf. Denn das ihnen zu Grunde liegende Ereignis läuft ab wie folgt: In einem Shared-Media-Ethernet ereignet sich eine Kollision. Die Überlagerung zweiter Ethernet-Frames führt dazu, dass die physikalische Ethernet-Signalisierung des Differential Manchester Codes gestört ist – in zufälliger Folge auch in der Form, dass kurze Zeiten eines elektrischen Null-Pegels auftreten.

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Abbildung 6.1: Die Ethernet-Runts weisen vermeintliche MAC-Adressen auf, die erkennbar defekt sind.

Abbildung 6.2: Die Ethernet-Runts weisen überwiegend eine Länge von zwölf Oktetten auf.

>>> NEW TECH

179

Kapitel 6 • OSI-Schichten 1 und 2

Abbildung 6.3: Nachweis einer TCP Retransmission im Zusammenhang mit einem IP-Paketfehler ■

■

■

■

180

Diese kurzen Null-Pegelzeiten können von einem Repeater nur gedeutet bzw. missverstanden werden als Ende eines Frames bzw. als so genanntes Inter Frame Gap (Pause zwischen zwei Frames). Da die vorgeschriebene Länge des Inter Frame Gaps von 96 µs jedoch nicht erreicht wird, sondern in viel kürzerem Abstand der vermeintlich nächste Frame eintrifft, und da die in solcher Art eintreffenden Kollisions-Reste nicht die Mindestlänge regulärer Ethernet-Frames erreichen, sondern eben nur kurze Schnipsel sind, steht der Repeater vor folgender Situation: Er ist verpflichtet, alle Signale weiterzugeben – also auch die Schnipsel. Da aber für alle Fälle gilt, dass kein Ethernet-Signal kürzer sein darf als zwölf Oktette bzw. (bei 10 Mbps Ethernet) 96 µs, muss der Repeater etwaige Kollisions-Schnipsel auf diese Mindestlänge von zwölf Oktette verlängern. Daraus ergibt sie die typische Länge von zwölf Oktette bei Ethernet-Runts. Dies erklärt, warum EthernetRunts nur in Ethernet-Segmenten auftreten, die mit Shared-Media-Verkabelung und Repeatern (Hubs) arbeiten. Die Bedingungen »normaler« Ethernet-Runts sind also damit hinreichend erklärt. Nun ist zu prüfen, ob die tatsächlich vorliegenden 12-OktetteFrames dem beschrieben Szenario entstammen bzw. entstammen können. Zweifel Nummer 1: Wenn denn Ethernet-Runts nur in Shared-MediaSegmenten auftreten können als Folge von Kollisionen und nachfolgender Repeater-Wirkung – wie können dann die vorliegenden 12-Oktette-Frames tatsächlich Kollisions-Runts sein, wo doch das aktuell vorliegende CampusLAN über Switches arbeitet? Zweifel Nummer 2: Wenn sich Kollisionen ereignen, ergibt sich zwingend (und zwar völlig unabhängig von der Position des LAN-Analyzers, sofern die beteiligten Ethernet-Stationen hinreichend weit voneinander entfernt sind), dass folgende weitere Bedingungen gegeben sind: (a) Es gibt nicht nur zwölf Oktette lange Runts, sondern bis maximal 64 Oktette lange Frames, die kollisionstypische Veränderungen aufweisen. (b) Es sind regelmäßig bei solchen längeren Kollisions-Frames die ersten Oktette der MAC-Adressen (vorne im Ethernet-Header) unbeschadet erhalten; dies ergibt sich daraus, dass vor dem »Zusammenprall« mit dem jeweils zweiten Kollisions-Frame über eine gewisse Laufzeit (und damit über eine gewisse Kabelstrecke) die Übertragung ungestört und fehlerfrei erfolgen konnte. Im vorliegenden Fall nährt genau das den nächsten Zweifel: Sämtliche 12-Oktette-Frames weisen keinerlei echte Reste der MAC Destination Address auf (ganz vorne im

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

■

Frame liegend). Dieser Zweifel verlangt, die im aktuellen Fall tatsächlich beobachteten Oktett-Folgen von 0xD0D0D0... und 0x434343... zu deuten. Wenn ein Repeater im Shared-Media-Ethernet defekte physikalische Signale aufnimmt, ist er verpflichtet, entsprechend ihrer Länge auf den AusgangsPorts Signale zu senden. Sind nun aber die Eingangs-Signale unleserlich, müssen die Ausgangs-Signale mit Ersatz-Bitmustern gefüllt werden. Typischerweise werden als Ersatz-Bitmuster entweder (binär) 010101... oder 101010... verwendet. Dies ergibt als Hexadezimal-Ausdruck 0xAAAA... oder 0x5555..., gelegentlich auch wechselnde Folgen wie 0xA5A5... oder 0x5A5A... und dergleichen mehr. Nun ist evident, dass die im aktuellen Fall sichtbaren MAC-Adressen (oder die dafür vorgesehenen ersten zwölf Oktette) mit den Hex-Mustern 0xD0D0... oder 0x4343... gefüllt sind. Die ihnen zu Grunde liegenden Bitmuster können ebenfalls von Ethernet-Repeatern nach Kollisionen verwendet werden, sind in bestimmten Situationen aber auch typisch für Switches. Ältere Switches können bei Puffer-Überlauf »unechte« Kollisions-Signale an die angeschlossenen Ethernet-Adapter senden, um sie von weiteren Übertragungen abzuhalten. Ein solches Verhalten wird gelegentlich auch als »back pressure« (Gegendruck) bezeichnet. Die hierbei gerne verwendeten Bitmuster sind eben 0xD0D0... oder 0x4343... – ganz wie im aktuellen Fall zu beobachten.

So weit die Betrachtungen der zwölf Oktette langen Pseudo-Runts – die, wie nun die Überlegungen gezeigt haben, keine Kollisions-Runts sein können. Vielmehr wird klar, dass tatsächlich die Switches im Verdacht stehen, diese MiniSchnipsel auf die Leitung zu bringen. Nun könnte immer noch eingewendet werden, dass Messfehler vorliegen könnten oder dass die oben angestellten Überlegungen unzutreffend wären. Da trifft es sich gut, wenn weitere Hinweise aufzufinden sind, die den sich verdichtenden Befund erhärten. Im vorliegenden Fall ergab die Analyse, dass nicht nur die Pseudo-Runts mit scheinbar kollisionstypischen Merkmalen zu finden sind, sondern daneben auch unscheinbare IP-Pakete. Diese fallen in der Analyse mit zwei verschiedenen Befunden auf: ■ ■

Die Länge des MAC-Frames (Ethernet) stimmt nicht mit der im IP-Header enthaltenen Längenangabe überein. Im Zusammenhang mit diesen defekten IP-Paketen stehen TCP Retransmissions – wobei schon auf den ersten Blick plausibel erscheint, dass der Defekt in der Erstübertragung die folgende Zweitübertragung zur Folge hat.

Dies sieht in der Event-Log-Datei von TraceMagic (hier: mit nachträglich eingesetztem Kommentar) wie folgt aus: ■ ■

Das IP-Paket in Frame Nr. 5468 ist defekt; die physikalische Frame-Länge stimmt mit der IP-Längenangabe nicht überein. Die in diesem IP-Paket enthaltene TCP-Sequenz wird in Frame Nr. 5486 als Retransmission ein zweites Mal übertragen.

>>> NEW TECH

181

Kapitel 6 • OSI-Schichten 1 und 2

Abbildung 6.4: Die Auswertung zeigt: Es gibt defekte IP-Pakete. Die Folge: TCP Retransmissions

So sehr sich aufdrängt, dass der angenommene Zusammenhang tatsächlich besteht, muss doch genauer hingesehen werden, um sicher zu sein. Es stellt sich nämlich folgende Frage: ■

■

Hat der TCP-Absender die Wiederholungsübertragung veranlasst, weil die Gegenstelle nicht das erwartete TCP-ACK (Acknowledgement bzw. Empfangsquittung) gesendet hat? Oder hat ein Router bzw. Switch, der das TCP/IP-Paket durchgeleitet hat, den Ethernet-Frame aus seinem Tx-Buffer erneut gesendet – etwa als Folge des »Erkennens« eines Sendefehlers?

Dies verlangt, in die Frames Nr. 5468 und 5386 hineinzusehen. Dabei ist Folgendes festzustellen: ■

■

■

■

182

Eine Überprüfung der TCP Sequence Number (TCP-Sende-Offset) ergibt, dass beide Pakete, jeweils gesendet von IP = 10.154.24.52, dieselbe Sequence Number enthalten, nämlich 77039534 bzw. 0x049787AE. Eine Überprüfung der IP-Paket-ID (eindeutiger IP-Paketzähler) ergibt, dass beide Pakete vom TCP-Absender stammen, da beide IP-Pakete eine jeweils andere Paketnummer tragen. Erheiternd am Rande: Es darf als sicher angenommen werden, dass es sich um einen Rechner mit Win9x oder WinNT4 handelt, da die beiden IP-Paketnummern wie folgt aussehen: 0x7D13 und 0x7F13. Das Auffällige daran ist, dass MS Windows-Rechner bis einschließlich WinNT4 nur das Hi-Byte hochzählen, nicht aber das Lo-Byte. Indirekt lässt sich also zusätzlich schließen, dass der Absender IP = 10.154.24.52 zwischen diesen beiden IP-Paketen noch ein drittes gesendet haben muss mit der IP-Paketnummer 0x7E13. Aber das ist nur eine kleine Nebenbetrachtung zum Schmunzeln. Ein Vergleich der Ethernet-Frame-Größen zeigt: Paket Nummer 5468 ist 1461 Oktette lang, Paket Nummer 5486 (mit der TCP Retransmission) ist 1518 Oktette lang. Das bestätigt, dass die TCP-Erstübertragung in Frame 5468 tatsächlich wegen eines physikalischen Defekts fehlgeschlagen ist und somit die Zweitübertragung notwendig gemacht hat. Ein Vergleich der Ethernet-Prüfsumme (FCS bzw. CRC) zeigt: Die im defekten Frame angegebene Prüfsumme enthält die Folge 0x43434343. Dies macht stutzig: War das nicht eine Ersatz-Bitfolge, die von Repeatern oder Switches verwendet wird?

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

■

Dies erzwingt einen Blick in den hinteren Teil des defekten Frames Nummer 5468 und siehe da: Es finden sich darin lange Folgen von 0x434343... und die letzten vier Oktette werden als CRC bzw. Prüfsumme des Ethernet-Frames missverstanden.

An dieser Stelle muss geklärt werden: Kann es eine reguläre Situation geben, die dazu führt, dass die letzten Oktette eines Ethernet-Frames mit Ersatz-Bitfolgen gefüllt sind? Die Antwort darauf lautet eindeutig: Nein, eine solche reguläre Situation gibt es nicht. Selbst einmal angenommen, es könnte sich um die Folge einer Kollision handeln (was angesichts der Switch-Umgebung schon ausgeschlossen sein dürfte!), so muss festgehalten werden: Wenn die maximalen Werte für Längenausdehnung des Shared-Media-Ethernets eingehalten sind sowie die maximalen Werte für die zulässige Signal-Laufzeit zwischen zwei Endpunkten (25,6 µs), können Kollisionen nur innerhalb der ersten 64 Oktette eines Ethernet-Frames auftreten, was zudem zum Abbruch der Übertragung eines jeden beteiligten EthernetAdapters bis spätestens zum 64. Oktette führt. Hier aber treten die Füllmuster 0x4343... weit hinten nach über 1.400 Oktette auf. Somit ist ausgeschlossen, dass es eine Kollisionseinwirkung gegeben haben könnte. Das führt zu folgenden Vermutungen, die beide letztlich zum Inhalt haben, dass ein Ethernet-Adapter oder ein Tx-Port eines Switches defekt ist oder aber störenden Außeneinflüssen unterlegen ist: ■

■ ■

Verdacht 1: Es kann einen defekten Tx-Buffer geben oder im Falle eines Switches ein fehlerhaft arbeitendes Shared-Memory-Modul (in dem die Packet Queue abgelegt wird) und die darin liegenden Frames werden bisweilen verfälscht. Verdacht 2: Das Sende-Modul ist defekt und schreibt Stopf-Bits in durchlaufende Pakete, ohne dass es dafür einen regulären Anlass geben würde. Verdacht 3: Adapter oder Switch-Port sind korrekt, aber es gibt störende Außeneinflüsse. Dies könnten Kriechströme sein, die über den Folienschirm der CAT-5-Kabel das Chassis von Adapter oder Switch-Port erreichen und dort, nach kurzer Aufladung der Buchse, zu Entladungen führen.

Die letzte Variante fällt nach einiger Betrachtung aus, weil ein solches Verhalten deutlich sporadisch wäre und keine wirklichen Regelmäßigkeiten erzeugen würde, wie sie in den 12-Oktette-Pseudo-Runts jedoch unzweifelhaft gegeben sind. Also bleiben die Verdachtsmomente 1 und 2 erhalten: Entweder ist der Ethernet-Adapter des Absenders defekt oder aber der letzte (vor dem Analyzer liegende) Switch.

>>> NEW TECH

183

Kapitel 6 • OSI-Schichten 1 und 2

Wie nun also sollte das unterschieden werden? Man könnte den Aufwand treiben, in jeder Teilstrecke des Switched LANs einen Analyzer anzuschließen, um mit Akribie nachzuweisen, bis zu welchem Punkt der Übertragung ein Ethernet-Frame gesund ist, und ab wann gestört. Diese Arbeit tut sich kein vernünftig denkender Mensch an, solange es noch andere Wege gibt, zum Ergebnis zu kommen. Also drängt die natürliche Faulheit des Menschen darauf, kreativ zu werden und siehe da, ein paar einfache Überlegungen führen uns näher ans Ergebnis heran: ■

■

■

■

Wenn der Ethernet-Adapter des Absenders defekt wäre, hätte der erste Switch auf dem Übertragungsweg den Frame verwerfen müssen, sofern es sich nicht um Cut-Through-Switches handelt, sondern um Store-AndForward-Switches. Das Cut-Through-Verfahren arbeitet wie folgt: Da sowohl Rx-Port wie auch Tx-Port mit derselben Bitrate arbeiten und da der Tx-Port bei Eintreffen des Frames am Rx-Port frei ist, wird sofort nach Ermittlung der MAC-Empfängeradresse damit begonnen, den Frame auf dem Tx-Port auszugeben, noch während der Frame am Rx-Port weiter einläuft. Das Store-And-Forward-Verfahren arbeitet immer mit Zwischenspeicherung des Frames im Switch, wenn entweder Rx-Port und Tx-Port mit unterschiedlichen Bitraten arbeiten oder wenn bei gleichen Bitraten der TxPort zur Zeit besetzt ist. Eine Überprüfung der MAC-Absenderadresse ergab, dass der Verkehrsweg vom sendenden Ethernet-Adapter bis zum Messpunkt über mehrere Switches lief: Es war völlig unwahrscheinlich, dass ein physikalisch defekter Frame alle Switches im Cut-Through-Mode hätte durchlaufen können. Also war damit zu rechnen, dass eben nicht der Ethernet-Adapter des IPAbsenders defekt war, sondern der letzte vor dem Messpunkt liegende Switch-Port. Zwischen Frame Nummer 5468 (TCP-Erstübertragung) und 5486 (TCPZweitübertragung) liegt ein Zeitraum von 0,2 Sekunden. Für den Fall, dass der Ethernet-Adapter des IP-Absenders die Übertragung nach 1.461 Oktette abgebrochen hätte, wäre die Retransmission noch aus dem Hardware-TxBuffer des Ethernet-Adapters vorgenommen worden, mit zweierlei Merkmalen: (a) Die Verzögerungszeit zwischen Erst- und Zweitübertragung wäre praktisch gleich Null. (b) Die IP-Paketnummer in beiden Ethernet-Frames (5468, 5486) wären identisch, da der IP-Treiber des Absenders gar nicht beteiligt wäre. Fazit insofern: Die Retransmission wurde vom TCP-Treiber des Absenders veranlasst – und das schließt definitiv aus, dass seitens des Absenders ein physikalischer Defekt erkannt worden wäre. Vielmehr hat der TCP-Treiber des Absenders erkannt, dass das fällige TCP-ACK der Gegenstelle nicht eintraf – was eben die Wiederholungsübertragung auslöst.

Es stellt sich also heraus, dass eine genaue Betrachtung der beiden TCP-Pakete erfolgen muss – mit Merkmalen auf Ethernet-Ebene, IP-Ebene, TCP-Ebene sowie Nutzdatenteil.

184

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Abbildung 6.5: TCP-Erst- und Zweitübertragung (1): Die TCP Sequence Number ist in beiden Paketen identisch (jeweils 77039534).

Es verdichtet sich also der Befund, dass der Defekt in einem der Switches im Core-Backbone liegen muss und zwar höchst wahrscheinlich im letzten Switch vor dem Messpunkt (Ethernet-Repeater zwischen Switch und Server). Um dies zu überprüfen, war nun zu fragen: Haben die Switches während ihrer Betriebsdauer defekte Frames erhalten und verworfen? (Was zu erwarten wäre, wenn Ethernet-Adapter von Endgeräten defekte Frames erzeugen würden.) Also wurden per Telnet die Zählerstände der Switches abgefragt: ■

■

Der unmittelbar vor dem Messpunkt liegende Switch war zu befragen, ob er von anderen, noch weiter davor liegenden Switches defekte Ethernet-Frames erhalten hat und ob er – falls das so sein sollte – diese defekten Frames verworfen hat. Der nächste Switch, der hinter dem aktuell verdächtigten Switch angesiedelt war, wurde ebenfalls abgefragt, um auf diese Weise zu testen, ob der vor dem Messpunkt liegende Switch (Server-Switch) nicht nur, wie vermutet, zum Server hin defekte Frames ausgab, sondern auch zum benachbarten, nächsten Switch – der das ja schließlich merken und in seinen Zählerständen vermerken müsste.

Es wurden also die Switches angesteuert und abgefragt und siehe da: Es ergab sich eine echte Überraschung!

>>> NEW TECH

185

Kapitel 6 • OSI-Schichten 1 und 2

Abbildung 6.6: TCP-Erst- und Zweitübertragung (2): Die IP-Paket-ID ist in beiden Paketen unterschiedlich (32.019 vs. 32.531).

Der Switch behauptete doch tatsächlich: ■ ■ ■

Er habe stolze 21.424.669 Unicast-Frames erhalten. Er habe nur schlappe 329.321 Unicast-Frames gesendet! Er habe zudem 28.978 Frames mit Frequenz- bzw. Signal-Fehlern erhalten (Alignment Rx).

Bei aller Liebe: Das kann nicht stimmen! Zumal das Verhältnis zwischen Bytes Rx und Unicast Rx kaum stimmen kann, wenn es mit dem Verhältnis zwischen Bytes Tx und Unicast Tx verglichen wird! Es ist völlig offenkundig: Dieser Switch arbeitet komplett falsch: ■ ■ ■

Möglichkeit 1: Die RX/TX-Funktionen sind einwandfrei, aber die Zählerstände sind falsch (was auch nicht tröstet). Möglichkeit 2: Die Zähler sind korrekt, dann sind die RX/TX-Funktionen defekt. Möglichkeit 3: Alles zusammen ist defekt und nicht mehr berechenbar.

Ganz gleich, welche der drei Möglichkeiten zutraf: Der Switch war auf jeden Fall schwer gestört. Da die Zählerstände nicht mehr widerspruchsfrei zu deuten waren unter der Annahme, dass der Switch lediglich auf irreguläre, äußere Ereignisse reagiere, blieb nur noch der Schluss: Der Switch war intern gestört.

186

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Abbildung 6.7: TCP-Erst- und Zweitübertragung (3): Die physikalische Ethernet-Paketgröße ist unterschiedlich (1.461 vs. 1518).

Dieser Befund würde sich auch mit allen vorherigen Beobachtungen und Schlussfolgerungen decken. Nachtrag: Es fanden sich noch weitere Effekte, darunter Ethernet-Frames mit Überlänge, beispielsweise mit 1.648 Oktette – ein Ereignis, das nur auf den Server-Switch selber unmittelbar zurückzuführen sein konnte. Denn wäre der Switch gesund und kämen die überlangen Frames von woanders her, ■ ■

so hätte der Switch das in seinen Zählerständen unter Giants Rx anzeigen müssen, so hätte der Switch diese überlangen Frames verwerfen müssen, nicht aber weiterleiten dürfen.

Weiterhin fanden sich Abfolgen defekter Pakete, in denen hauptsächlich Füllmuster zu finden waren, aber eben auch Nutzdaten – und zwar identisch in den verschiedenen Schrott-Frames, was nur wie folgt gedeutet werden konnte: Aus dem Tx-Buffer heraus wurden Inhalte in mehrere defekte Frames eingestreut. Alles das machte am Ende den Befund unanfechtbar: Der dem Server gegenüber liegende Switch musste defekt sein. Jede Annahme, die Fehler auf eine andere Quelle zurückzuführen, scheiterte früher oder später an Widersprüchen.

>>> NEW TECH

187

Kapitel 6 • OSI-Schichten 1 und 2

Abbildung 6.8: TCP-Erst- und Zweitübertragung (4): Die Erstübertragung ist hinten mit Stopf-Bits aufgefüllt (0x434343...).

Abbildung 6.9: Die Switch-Statistik des zum Analyzer hin liegenden Ports

188

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Selbst die Annahme, der Switch könne möglicherweise Opfer von Erdungsfehlern und Überspannungen sein, konnte insbesondere die Regelmäßigkeit der Pseudo-Runts nicht erklären.

HINWEIS Fazit: Ein vordergründig simples Fehlerbild (Ethernet-Runts) war der Einstieg in den Nachweis, dass eine große Zahl von Backbone-Switches defekt war und ausgetauscht werden musste.

In einer internen E-Mail zweier Mitarbeiter des Herstellers wies der eine Kollege den anderen darauf hin, dass eine Messung bzw. Analyse, die von Synapse: Networks durchgeführt werde, schwerlich angreifbar wäre. Das Interessante daran war, dass diese E-Mail aus den USA kam. Manchmal ist dieser Planet doch kleiner, als man denken möchte. Die Lehren daraus sind:

HINWEIS Klare Befunde auf dem Physical-Layer sind manchmal schwieriger, als es auf den ersten Blick scheint. Insbesondere ist der alten Einsicht zu folgen, dass unbedingt Merkmale aller vertretenen Protokolle berücksichtigt werden müssen, um die Widerspruchsfreiheit der Annahmen bzw. Befunde sicherzustellen.

In diesem Falle halfen die TCP Retransmissions, der zeitliche Abstand zwischen Erst- und Zweitübertragung, die IP-Paketnummern sowie zufällig in die Pakete eingestreute Stopf-Bits, nach langer Prüfung und Überlegung den sicheren Befund zu stellen. Diese schöne Kombination verschiedenster Hinweise und Abhängigkeiten machte dieses Beispiel geeignet, an dieser Stelle und zu diesem Zwecke aufgeführt zu werden.

6.2.3

Defekte Ethernet-Frames (2): Switch-Fehler

Quelle: Castrop-Rauxel, 2002.

Dieses Beispiel eignet sich hervorragend, um verschiedene Effekte zu zeigen, die genauso interessant wie übel sind, weil sie zu Fehldeutungen führen können. Im vorliegenden Fall ging es eigentlich darum, Fehler in Voice over IP Verbindungen aufzudecken. Seit Wochen schon waren die Lieferanten und Hersteller dabei, mit eigenen Untersuchungen bzw. Messungen dem nachzugehen, wobei sowohl im Hauptsitz wie auch in den Niederlassungen des Kunden vorgegangen wurde.

>>> NEW TECH

189

Kapitel 6 • OSI-Schichten 1 und 2

In der Niederlassung in Castrop-Rauxel, in welcher die folgenden Messdaten entstanden, hatte sogar der Hersteller der Telefonanlagen permanent (über Wochen laufende) Messgeräte installiert und die folgenden gezeigten Fehler nicht gesehen ..., was Bedenken auslöst angesichts der Annahme, dass die in Rede stehenden Fehler nicht nur am Tage der Anwesenheit des Verfassers auftraten. Zur Sache: Der Analyzer wurde an einem Mirror-Port angeschlossen. Der Switch stand gegenüber dem WAN-Router, der die Verbindung zum Hauptsitz herstellte. Gespiegelt wurde am Switch der Port, der am Router angeschlossen war. Im Ergebnis waren also alle Daten zu sehen, die in Castrop-Rauxel vom Hauptsitz kamen bzw. zum Hauptsitz hin gesendet wurden. Da schon im Vorfeld bekannt war, dass es IP-Paketverluste gab, wurde am Ende der Messung mit TraceMagic eine automatische Auswertung der TCP/IPProtokolle vorgenommen. Hierbei nun traten Ergebnisse auf, die im Detail wert sind, genauer betrachtet zu werden – Ergebnisse, die beweisen, dass Fehler in der Physik und Ereignisse auf den höheren Schichten nicht getrennt betrachtet werden dürfen. Die wesentlichen Hinweise sind sämtlich in der Standard-Ergebnis-Datei der TCP/IP-Auswertung enthalten: TM.SM.SpiderMagic.TABLES.~~IP~~.TXT

In verschiedenen Abschnitten dieser Berichts-Datei ergeben sich Hinweise, die zunächst abwegig oder verwirrend erscheinen (können), dann aber nach und nach Sinn ergeben (wie zu sehen sein wird) (siehe Abbildung 6.10). Die Statistik ist wie folgt zu lesen: ■

■

IP Header Duplicated/Possible MAC multiple Transmission: TraceMagic hat erkannt, dass ein IP-Header mehrfach identisch auf der Leitung war. Als mögliche Ursache wird auf eine Mehrfachübertragung seitens einer MACKomponente hingewiesen. Solche Fehler sind (außerhalb von Token-Ring Source-Route-Broadcasts) in aller Regel mit Defekten Adapter-Karten oder Switch-Tx-Funktionen zu erklären. Es ergibt sich also ein entsprechender Verdacht. IP MAC Broadcast/Multicast – Multicast/Total – TCP: Niemals dürfen TCPPakete auf dem MAC Layer als Broadcast oder Multicast adressiert sein. TCP-Pakete dürfen nur eindeutig adressiert unterwegs sein. Sind TCPPakete dennoch als Broadcast oder Multicast adressiert, weist dies regelmäßig auf schwere Fehler hin – entweder in der Logik des Absenders, oder in der Logik/Physik aktiver Vermittlungskomponenten (Router, Switches). Es ist übrigens bezeichnend, dass von den selbst ernannten Marktführern im Analyse-Bereich kaum ein Analyzer auf diesen Fehler hin prüft. Im vorliegenden Fall jedenfalls wird ein Verdacht sichtbar, dem nachzugehen ist.

Ist erst einmal ein begründeter Verdacht gegeben, werden weitere Hinweise gesucht, die in diesem Fall in derselben Berichts-Datei vorhanden sind (siehe Abbildung 6.11).

190

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Abbildung 6.10: Die Statistik zeigt an: »IP Header Duplicated/Possible MAC multiple Transmission = 14 (Packets)« und »TCP Multicast/Total: 6 (Packets)«. Beides weist auf schwere Fehler hin.

Die Statistik der TCP Retransmissions (TCP-ReTx) weist neben »normalen« TCP-Wiederholungsübertragungen auf Ereignisse, die zwar Retransmissions äußerlich ähneln (dieselbe TCP Sequence Number taucht mehrfach auf, was für sich allein betrachtet wie eine Retransmission aussehen kann), die aber tatsächlich keine Retransmission auf TCP-Ebene sein können (weil die IP-Paketnummern ebenfalls identisch sind) und die zugleich auch nicht in Folge von lokalem IP-Routing auftreten können (weil die IP-TTL-Werte ebenfalls identisch sind) (siehe Abbildung 6.12).

>>> NEW TECH

191

Kapitel 6 • OSI-Schichten 1 und 2

Abbildung 6.11: Die Statistik zeigt an: »TCP: Errors: ReTx etc/HdrDupl/NoReTx: 8 (Packets)«. Hinweis auf TCP-Header, die doppelt (mehrfach) auf der Leitung waren

Der nächste Hinweis darauf, dass sich in den Messdaten offenkundig unerfreuliche Fehler ankündigen, findet sich im Nachweis der Absender-MAC-Adressen in Verbindung mit den Absender-IP-Adressen. Im vorliegenden Fall wurden die Pakete des Absenders IP = 192.168.80.106 mit (angeblich) insgesamt fünf verschiedenen MAC-Adressen ins lokale LANSegment gesendet.

192

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Abbildung 6.12: Die Statistik zeigt an: Nachweis der MAC-Adressen, die als Absenderkennungen in IP-Paketen sichtbar wurden IP-Adresse

MAC-Adressen

192.168.80.106

000216.C2E341 02C016.C2E341 00BF16.C2E341 03C016.C2E341 04C016.C2E341

Tabelle 6.1: Fett dargestellt: Die jeweils ersten beiden Adress-Oktette der MAC-Absenderadressen. Sie erscheinen als Mutationen der ursprünglichen, richtigen Adresse.

Sollte es so sein, dass fünf verschiedene Router die Pakete ins lokale LANSegment brachten? Das konnte nicht sein, da in der kleinen Betriebsniederlassung von Castrop-Rauxel nur ein einziger Router stand, dessen Verbindung zum Switch über den Mirror-Port am Switch gespiegelt wurde. Es stellte sich also immer weiter der Verdacht heraus, dass MAC-Adressen verfälscht oder sonstwie Fehler in der Logik und/oder der Physik gegeben waren. Zur Eingrenzung des Geschehens war also nach weiteren Hinweisen zu suchen. Der Einzelnachweis des Fehlerbildes »IP Header Duplicated/Possible MAC multiple Transmision« weist mehrere IP-Adressen aus, darunter die Absenderadresse IP = 192.168.80.106 (hier markiert, weil hier die meisten Fehlerereignisse in der Statistik ausgewiesen sind). Es ist daher offensichtlich, dass vermutlich am schnellsten Klarheit zu gewinnen ist, indem der Adresse IP = 192.168.80.106 nachgegangen wird. Verschiedene weitere Ausschnitte der Berichts-Datei weisen auf dieselben oder auf ähnliche Ereignisse hin. >>> NEW TECH

193

Kapitel 6 • OSI-Schichten 1 und 2

Abbildung 6.13: Die Statistik zeigt an: Nachweis der MAC-Adressen, die als Absenderkennungen in IP-Paketen sichtbar wurden

Abbildung 6.14: Die Statistik zeigt an: Nachweis der Anzahl von Mehrfachübertragungen von TCP-Paketen des Absenders IP = 192.168.80.106

Abbildung 6.15: Die Statistik zeigt an: Nachweis der MAC-Adressen, die als Absenderkennungen in IP-Paketen sichtbar wurden

194

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Der Blick auf den vollständigen Einzelnachweis aller TCP/IP-Ereignisse von IP = 192.168.80.106 gibt einen Überblick.

Abbildung 6.16: Einzelnachweis zu IP = 192.168.80.106 (oberer Ausschnitt zu IP)

Es wird nunmehr deutlich, dass offenkundig erhebliche Fehler vorliegen. Die letzte Bewertung jedoch verlangt, den Ereignisablauf zu betrachten, am Ende anhand der echten Paketaufzeichnung (Trace). Der Ereignisnachweis von TraceMagic (Event-Log) in der Datei TM.HIT. FRAMES.*.LOG.TXT braucht nur nach der IP-Adresse 192.168.80.106 durchsucht zu werden und schnell ist die richtige Fundstelle erkannt. (Es braucht nur nach dem Ereignistext IP Hdr.Dupl. gesucht zu werden, wie er auch in der Ergebnis-Statistik verwendet wird.)

>>> NEW TECH

195

Kapitel 6 • OSI-Schichten 1 und 2

Abbildung 6.17: Einzelnachweis zu IP = 192.168.80.106 (unterer Ausschnitt zu TCP)

In der Trace-Datei Nummer 28 erkennt TraceMagic bei Paket Nummer 10376 Folgendes: ■ ■ ■

■

196

Die Adresse IP = 192.168.80.106 wird von einer neu aufgetretenen MACAdresse ins LAN gesendet: MAC = 00BF16.C2E341. Es handelt sich um eine MAC-Broadcast/Multicast-Adresse. Ein Vergleich der Pakete 10376 und 10362 zeigt, dass die darin liegenden IPHeader identisch sind (was außerhalb von Token-Ring Source-Route-Broadcasts nicht sein darf). Neben den IP-Adressen ist die IP-Paket-ID 3244 ein entsprechender Hinweis. Also wäre der IP-Header doppelt auf der Leitung. Ein Vergleich der Pakete 10376 und 10369 kommt zum selben Ergebnis. Also wäre der IP-Header sogar dreifach auf der Leitung.

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Abbildung 6.18: Ereignisnachweis zu IP = 192.168.80.106 im TraceMagic Event-Log: In Trace-Datei Nr. 28 zeigt sich, dass eine bestimmte TCP-Sequenz mehrfach auf der Leitung ist und zwar in den Paketen Nummer 10362, 10369, 10376. Die beiden mittleren Doppelzeilen, durch eine Klammer von Schrägstrichen zusammengehalten, weisen auf Paketvergleiche hin, die zu dem genannten Ergebnis führen. ■

■

Das Paket Nummer 10376 enthält einen TCP-Header. Da TCP-Pakete nicht als MAC-Broadcasts/Multicasts unterwegs sein dürfen, wird dies als Fehler erkannt und ausgewiesen. Das Paket Nummer 10376 enthält einen TCP-Header, der bereits in vorangegangenen Paketen enthalten war – was dem Befund entspricht, der auf IPEbene bereits geliefert wurde.

Nun stellen sich die folgenden Fragen: ■ ■

Stimmt dieser Befund oder könnte hier ein Irrtum, eine Fehldeutung vorliegen? Wenn der Befund stimmt, gibt es Hinweise auf Ursachen und nähere Hinweise auf den genauen Hergang des Ereignisses?

Hier bleibt nun nichts anderes mehr übrig, als in die identifizierten Fundstellen hineinzusehen. Eine Untersuchung der Ethernet-Frames, die im TraceMagic-Event-Log ausgewiesen wurden, zeigt: ■ ■

■

Nur die erste Übertragung des TCP-Pakets weist reguläre Längenwerte auf bzw. ist physikalisch mit zulässiger Länge unterwegs. Die beiden Folgepakete sind unzulässig lang. Da bei Ethernet-LANs die höchstzulässige Frame-Länge bei 1.518 Oktette liegt, sind Werte, die darüber liegen, auf Defekte zurückzuführen. Hier ist keine andere Deutung möglich als die, dass der Switch, an dessen Mirror-Port die Messung stattfand, fehlerhaft arbeitet. Sowohl das zweite wie auch das dritte Paket (also beide Nachfolgepakete) weisen in auffälliger Weise denselben »Anhang« auf, will sagen: Die DatenBytes, die über die tatsächlich zu sendenden Daten hinaus angehängt sind, sind in beiden Überlängenpaketen identisch. Somit ist klar, dass der Switch nicht nur mehrfach den Datenanteil des Originalpakets gesendet hat, sondern auch mehrfach (nämlich zweimal) den unzulässigen Überhang (durch simples Anhängen an den regulären Datenteil).

>>> NEW TECH

197

Kapitel 6 • OSI-Schichten 1 und 2

Abbildung 6.19: Analyzer-Trace mit Ereignisablauf (1. Bild): Es ist deutlich zu erkennen, dass defekte Ethernet-Frames vor und nach dem Referenzpaket Nummer 10376 vorhanden sind.

Abbildung 6.20: Es wird ein Filter auf den Hex-Code der Adresse IP = 192.168.80.106 gesetzt.

Bis hierhin gekommen, ist einwandfrei bewiesen, dass der Ethernet-Switch, an dem gemessen wurde, einen Fehler hat. Es bleibt allein die Frage: Ereignen sich diese Fehler nur am Mirror-Port oder auch auf den anderen, produktiven Switch-Ports? Es bleibt eine akademische Frage, ob man es darauf noch ankommen lassen möchte.

198

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Abbildung 6.21: Filtermaske im Zusammenhang mit dem Referenzpaket 10376

Abbildung 6.22: Analyzer-Trace mit Ereignisblauf (2. Bild): Drei Ethernet-Frames mit identischem TCP-Inhalt (Pakete Nummer 10362, 10369, 10376). Jetzt schon sichtbar: Das erste TCP-Paket ist kürzer als die beiden Nachfolger.

>>> NEW TECH

199

Kapitel 6 • OSI-Schichten 1 und 2

Abbildung 6.23: Analyzer-Trace mit Ereignisablauf (3. Bild): Die beiden Nachfolgepakete enthalten deutlich mehr Daten als die Erstübertragung. Frage: Was davon ist nun richtig?

Der Kunde jedenfalls veranlasste sofort den Austausch der Switches (es gab eine Vielzahl davon mit identischer Konfiguration in verschiedenen Niederlassungen). Es fehlt noch ein Hinweis, warum dieses Beispiel als so interessant einzustufen ist. Eine MAC Layer Analyse weist natürlich sofort die entsprechenden FehlerFrames aus (Überlänge, Prüfsummen-Fehler). Das aber ist nicht immer so trivial, wie es hier erscheinen mag: ■ ■

■

■

200

Die Aussagen über MAC Layer Fehler sind oftmals nur während der Messung zu sehen, während der Analyser quasi »online« arbeitet. Nicht jeder Analyzer schreibt automatisch Fehlerstatistiken in Dateiform auf die Festplatte (etwa im .CSV-Format) und falls doch, so sind es eben oft nur Statistiken ohne Hinweis auf die Fundstellen (sofern überhaupt die Pakete aufgezeichnet wurden). Nur bei einem Analyzer, der online ein Event-Log mitschreibt, in welchem neben der Ereignisbeschreibung auch der Name der Trace-Datei sowie die entsprechenden Paketnummern angegeben werden, ist hilfreich. Viele Analyzer sind zu solchen Event-Logs nur unzureichend in der Lage. Schon allein die Fähigkeit, verschiedene Pakete miteinander zu vergleichen (wie im oben im Event-Log von TraceMagic sichtbar), ist bei der OnlineAnalyse (Echtzeit-Analyse) nicht gegeben. >>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Abbildung 6.24: Analyzer-Trace mit Ereignisablauf (4. Bild): Die Angaben zur Länge der Pakete schwankt: Die Erstübertragung in Paket Nummer 10362 ist auf Ethernet-Ebene mit 206 Oktetten regulär (diese Länge stimmt nahtlos mit der IP-Längenangabe von 188 Oktetten überein). Die beiden Nachfolgepakete weisen unzulässige Längen von jeweils mehr als 1.518 Oktetten zu (maximale Ethernet-Frame-Größe). ■

Ohne Betrachtung der MAC-Fehler sind die Wirkungen solcher Ereignisse auf der Ebene von IP und TCP nicht immer sofort eindeutig interpretierbar. Vor allem ist immer die Frage zu beantworten: Gehen diese Fehler aufs Konto des ursprünglichen IP-Absenders oder wurden sie von aktiven Netzwerk-Komponenten verursacht (Switches, Router)?

Nun könnte der Leser einwenden: Na ja, was soll das Ganze, die Pakete mit Überlängen werden halt von jedem Empfänger verworfen!? Hier wäre zu entgegnen: Das aktuell gewählte Beispiel macht es in der Tat leicht, den Fehler gering zu schätzen. Anders sieht es aus, ■ ■

wenn die künstlich verlängerten Pakete innerhalb der maximal erlaubten Ethernet-Frame-Größe von 1518 Oktette bleiben, wenn zudem die Ethernet-Prüfsummen stimmen, weil es zum Fehlerbild des Switches gehört, die fälschlich verlängerten Ethernet-Frames mit korrekten MAC-Prüfsummen auszustatten!

>>> NEW TECH

201

Kapitel 6 • OSI-Schichten 1 und 2

Spätestens bei solchen Fehlerabläufen (die der Autor mehrfach zu erleben die Freude hatte) ist klar, dass eine reine MAC Layer Analyse sogar gänzlich fehlschlagen kann. Somit lautet das Fazit dieses Beispiels: Unter speziellen Bedingungen können MAC-Fehler sogar nur ausschließlich über eine intelligente Analyse der IP- und TCP-Pakete nachgewiesen werden. Der Verfasser kann versichern, dass immer wieder mal solche Fehlerbilder auftreten – es handelt sich also mitnichten um einen akademischen Hinweis, der ansonsten ins Museum gehörte!

6.2.4

Defekte Ethernet-Frames (3): Adapter-Fehler

Quelle: Straelen (Niederrhein), 2001.

Dieses Beispiel ist wichtig, weil es zeigt, dass die Dinge oft anders liegen, als man denken möchte, und weil es beweist, dass herkömmliche LAN-Analyzer oft den Wald vor lauter Bäumen nicht erkennen können, wenn nur leichter Nebel auftritt. Der Kunde gab folgende Fehlerbeschreibung ab: »Fehlerbeschreibung: Vielfältiger Natur. Prio-Problem: Excel-Dateien unterschiedlichster Natur werden seit der 2. KW auf ca. 15 Clients defekt, wenn sie aus einem Netzwerk-Laufwerk (Novell NetWare 4.2) aufgerufen werden. Dateien auf dem lokalen Laufwerk sind nicht betroffen. Werden lokal bearbeitete Dateien per copy übers Netz mit anderen Usern ausgetauscht, sind Daten verfälscht. Zwischen Weihnachten und Neujahr wurden alle Etagenverteiler von FDDI und Hubs auf Gigabit-Ethernet (...) umgestellt. Die betroffenen Stationen arbeiten über IPX. Es gibt Stationen, die problemfrei arbeiten. Die Fehler sind nicht auf allen Stationen konstant. Ca. 1/3 der Arbeitszeit sind keine Effekte erkennbar. Wir können uns keinen Reim mehr machen. Die Excel-Dateien steuern unsere Produktion und werden für die Preiskalkulation genutzt. Katalogwechsel und Warenlieferungen für 150 Niederlassungen sind gefährdet.« Hier scheinen sich tatsächlich bei erster Betrachtung keine sinnvollen Varianten anzubieten. Also LAN-Analyzer an die Leitung und dann erst mal sehen, was sich da zeigt. Der nahe liegende Verdacht, dass Client/Server-Dialogfehler vorlägen, wurde schnell ausgeräumt. Tatsächlich wurden Ethernet-Frames massiv auf sehr prägnante Weise verfälscht. Die Darstellungen zeigen wichtige Einzelheiten: ■

202

Es kann sich nicht um Kollisionsereignisse handeln (siehe voriges AnalyseBeispiel); eines der Kriterien hierfür ist, dass in einem regulär aufgebauten Ethernet-Segment Kollisionen lediglich in Frames sichtbar werden können, die maximal 64 Oktette lang sind.

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

■

■

■

Die verfälschten Ethernet-Frames zeichnen sich sämtlich dadurch aus, dass sie mit Stopf-Bits aufgefüllt sind, in Hex-Folgen dargestellt als 0x343434... oder 0xD0D0D0 (siehe Screenshots). Die eingefügten Stopf-Bit-Muster tauchen mal ganz vorne in den Frames auf, mal ganz hinten. Einige der Frames bestehen sogar ausschließlich nur aus diesen Stopf-Bits. Dies macht klar, dass eine aktive Komponente (Ethernet-Adapter, Tx-Port eines Switches oder Routers) diese Verfälschungen vorgenommen haben muss. Einige der defekten Frames werden auf MAC Layer so gedeutet, als wären die CRC-Prüfsummen korrekt. Hier bleibt die Frage, ob der aktuell verwendete Analyzer (LANdecoder32) das missdeutet oder ob zufällig diese Deutung zutrifft – was zur Folge haben könnte, dass empfangende EthernetAdapter die verfälschen Frames für gesund halten könnten. In diesem Falle bliebe nur die Hoffnung, dass die Treiber der höheren Schichten die Missbildungen noch erkennen und herausfiltern.

Es zeigt sich auch in diesem Beispiel, dass defekte Frames bei näherer Betrachtung äußerst aufschlussreich sein können.

Abbildung 6.25: Das Event-Log von TraceMagic zeigt schon während der Analyse massiv verfälschte Ethernet-Frames an.

Die Diagnose lautete also: Eine aktive Komponente verfälscht durchlaufende Frames und sondert zudem noch völlig eigenständig Schrott-Schnipsel ab, die überhaupt keinen Sinn mehr ergeben. War dies der gesuchte Zusammenhang zu dem vom Kunden beschriebenen Fehler, dass Excel-Dateien korrumpiert wurden? Dies war immer noch die Frage.

>>> NEW TECH

203

Kapitel 6 • OSI-Schichten 1 und 2

Abbildung 6.26: Um defekte Frames aus den Trace-Dateien herauszufiltern, wird ein TraceFilter definiert, der die typischen Stopf-Bit-Muster enthält (0x3434, 0xD0D0 etc.).

Abbildung 6.27: Zwei defekte Ethernet-Frames im Vergleich: Die Stopf-Bits 0x3434... liegen mal ganz vorne, mal ganz hinten. 204

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Abbildung 6.28: Ein einzelner verfälschter Ethernet-Frame wird betrachtet: Die Protokoll-Header vorne im Frame sind unangetastet gesund (Teilfenster links); im hinteren Teil des Frames sind Stopf-Bits eingefügt (Teilfenster rechts unten). Die im IPX-Header angezeigte Länge von 690 Oktetten wird nicht erreicht, da der Ethernet-Frame nach 275 Oktetten abgeschnitten wurde (siehe Längenangaben im Teilfenster unten rechts).

Die Antwort hierauf ergab sich ganz pragmatisch: Nachdem der Fehler auf dem Physical-Layer durch Austausch behoben worden war, waren auch die DateiFehler behoben. Dies führt zu der Annahme, dass immer wieder einige der defekten Frames von den Client-Treibern nicht zuverlässig aussortiert bzw. verworfen worden waren. Denn wäre dies geschehen, hätte niemals eine übers Netzwerk arbeitende Applikation betroffen sein können. Was genau hier im Treiber-Werk der Client-PCs geschehen war, ließ sich nicht mehr bis zum letzten Beweis nachvollziehen. Dem Kunden reichte es (verständlicherweise), dass die Ursache gefunden und die Wirkung beseitigt war. Die genaue Kausalkette zu verfolgen, konnte der Kunde zu Recht nicht mehr als seine Aufgabe betrachten.

>>> NEW TECH

205

Kapitel 6 • OSI-Schichten 1 und 2

Abbildung 6.29: Event-Log: Ein Überblick über MAC-Adressen und Frame-Längen. Viele der verfälschten Frames haben Überlänge (länger als die erlaubten 1.518 Oktette).

Abbildung 6.30: Ein besonders auffällig verfälschter Ethernet-Frame, der ausschließlich aus der Hex-Folge 0xD0D0D0... besteht

206

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Abbildung 6.31: Die Tabelle der gefundenen MAC-Adressen weist auffällig viele PseudoMAC-Adressen auf, die Opfer der Verfälschungen wurden.

>>> NEW TECH

207

Kapitel 6 • OSI-Schichten 1 und 2

Abbildung 6.32: Die Trace-Statistik weist den Anteil der Frames aus, die zu klein (< 64 Oktette) oder zu groß (>1.518 Oktette) sind.

HINWEIS Fazit: Wieder einmal konnte über defekte Ethernet-Frames nachgewiesen werden, dass eine aktive Komponente durchlaufende Pakete verfälschte, durcheinander würfelte und zum Teil sogar gänzlich durch Schrott-Sequenzen ersetzte.

208

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

HINWEIS Die Lehre hieraus ist: Wenn nicht gerade überdeutliche Symptome vorliegen wie Frameüberlängen (< 1.518 Oktette), können Frame-Verfälschungen schnell missdeutet werden, sofern man sich auf Kabelfehler oder Kollisionen festlegt (die in einem Switched LAN sowieso ausgeschlossen sein sollten).

6.2.5

Switch-Fehler: Paketvervielfältigungen

Quelle: Bergisch-Gladbach, 2002.

Eine interessante Erscheinung sind Vervielfältigungen von LAN-Frames durch Switches. Im Jahr 2002 wurde dergleichen ein paar Mal beobachtet; jedes Mal bei Switches desselben Herstellers. Es scheint sich also um ein Problem der Baureihe gehandelt zu haben. Da die Fehler über Patches behebbar waren, waren sie zwar störend, aber am Ende erträglich. In allen Fällen handelte es sich um Layer-3-Switches und die Vervielfältigungen fanden jeweils nach dem Router-Hop statt. Insofern handelt es sich um ein klares, geschlossenes Fehlerbild. Schlimm an einem solchen Geschehen (für das ein Beispiel folgen soll) waren bzw. sind folgende Begleiterscheinungen: ■

■

■

■

Sämtliche Analyzer, die vom Verfasser selbst oder von Dritten an den jeweiligen Leitungen arbeiteten, wiesen die Ereignisse als Retransmissions aus und da in allen Fällen überwiegend mit TCP gearbeitet wurde, eben als TCP Retransmissions. Selbst teure Analyzer für Preise weit oberhalb von 10.000 EUR gaben diesen Befund aus. Korrekte Befunde gibt es in diesen Fällen über TraceMagic, da dieses Expertensystem die notwendigen Unterscheidungen treffen und den Fehler auf den Switch lenken kann (statt auf den Absender, der ja für TCP Retransmissions verantwortlich wäre). Der Unterschied zwischen einer TCP Retransmission und einer Paketvervielfältigung liegt darin, dass der TCP-Absender im Falle einer TCP Retransmission auf IP-Ebene den Paketzähler erhöht, wenn dieselbe TCP Sequence erneut gesendet wird. Bei Paketvervielfältigung durch einen Switch ist dieselbe IP-Paket-ID erneut zu sehen. Weiterhin muss unterschieden werden zwischen IP Local Routing (IP Local Loop) und einer Vervielfältigung. Handelt es sich bei dem Switch um einen Layer-3-Switch (Bridge/Router), so könnte es je nach Gestaltung des Messpunkts bzw. Mirror-Ports sein, dass das TCP-Paket einmal vor und einmal nach dem Router-Hop gesehen wird. Hier ist die Vervielfältigung vom Router-Hop wie folgt zu unterscheiden: Bei einem Router-Hop wird der IP TTL-Wert vermindert; bei einer Vervielfältigung bleibt er gleich.

>>> NEW TECH

209

Kapitel 6 • OSI-Schichten 1 und 2

■

Zuletzt muss noch berücksichtigt werden, dass bei Multi-Port-Mirroring Missverständnisse auftreten können: Werden die Daten mehrerer SwitchPorts auf den Mirror-Port kopiert, könnten IP-Broadcasts/Multicasts entsprechend mehrfach auf den Mirror-Port gelangen, da ja Boadcasts/Multicasts auf jedem Port ausgegeben werden. Hier wäre die einfachste Überprüfung des Befundes, zu klären, ob die in Verdacht stehenden Pakete Broadcasts/Multicasts sind oder eben Unicasts (eindeutig adressierte Pakete). In denselben Zusammenhang gehört der Hinweis, dass bei AllPorts-Mirroring (die Daten aller Ports werden auf dem Mirror-Port ausgegeben) jeweils nur die Rx- oder die Tx-Pakete ausgespiegelt werden dürfen! Würden von allen Ports sowohl die Rx-Pakete wie auch die Tx-Pakete gespiegelt, führte dies zwingend zu einer Paketverdopplung in den Messdaten, da ja ein jegliches Paket auf der Eingangsleitung als Rx-Paket erfasst würde und auf der Ausgangsleitung als Tx-Paket.

Dieses alles wohl berücksichtigt, gibt es doch Fälle, bei denen klar ist, dass eine Paketvervielfältigung durch den Switch vorliegt. Bei dem folgenden Beispiel schaffte es ein Gigabit-Ethernet-Switch, die GigabitLeitungen mit bis zu 30% Netzlast mittels vervielfältigter Pakete anzufüllen. Das vertrackte, wenn die Analyzer TCP Retransmissions anzeigen, ist: ■ ■

■

Der Kunde denkt: »Das Netzwerk ist langsam«, sprich: Die Switches sind zu langsam für den vielen Verkehr auf der Leitung. Der Kunde folgert daraus: Es gingen wegen der überlasteten Switches dermaßen viele TCP-Pakete verloren, dass deswegen eben viel TCP Retransmissions seitens der Absender nötig würden. (Dass das rein zeitlich gar nicht hinkommt, da die für Retransmissions nötigen Wartezeiten zwischen den Paketen gar nicht vorhanden sind, wird bei diesem Szenario gerne übersehen.) Der Kunde kommt also zu dem Schluss: Er braucht jetzt 10-Gigabit-Trunks oder Terabit oder das Beamen der Daten über Subraum-Frequenzen via Traktorstrahl. ...

Bei korrekter Deutung der Daten wird dagegen klar: Wird dem Switch (den Switches) das fehlerhafte Verhalten abgewöhnt, kommen sowohl die benachbarten Switches wie auch die kommunizierenden Endgeräte (Server, Clients, Printer) zur Ruhe und können ohne diese Belästigung ihrer Arbeit nachgehen. Das folgende Beispiel bietet nicht von allem etwas, aber doch einige der vorgenannten Elemente: ■ ■ ■ ■

210

Es sind von vielen IP-Pakets drei Exemplare zu sehen. Das erste Exemplar weist den Wert TTL = 128 aus (Original vom Absender, noch vor dem Router-Hop). Das zweite Exemplar weist den Wert TTL = 127 aus (nach dem Router-Hop). Das dritte Exemplar weist ebenfalls den Wert TTL = 127 aus und stellt die Vervielfältigung dar; die Differenz im Zeitstempel zeigt, dass tatsächlich zwei Übertragungen hintereinander stattfanden (und dass nicht etwa der Analyzer in seinem Eingangs-Puffer den Fehler machte).

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Somit ist klar, dass der betroffene Switch einen für die Netzlast unerfreulichen Fehler macht.

Abbildung 6.33: Die Erstübertragung des IP-Pakets mit der Paket-ID 33156 (vor dem Router-Hop mit TTL = 128)

Abbildung 6.34: Die Zweitübertragung des IP-Pakets mit der Paket-ID 33156 (nach dem Router-Hop mit TTL = 127)

>>> NEW TECH

211

Kapitel 6 • OSI-Schichten 1 und 2

Abbildung 6.35: Die Verdopplungsübertragung des IP-Pakets mit der PaketID 33156 (nach dem Router-Hop mit TTL=127)

Abbildung 6.36: Die Darstellung im Event-Log von TraceMagic: Die Verdopplung der IP-Header wird erkannt; ebenfalls, dass es sich nicht um TCP Retransmissions handelt.

Bei einem solchen Szenario können Zweifel aufkommen, ob der Befund tatsächlich stimmt: ■

Denkbar wäre, dass nur der Mirror-Port die Pakete verdoppelt, nicht aber der Switch am »echten« Ausgangs-Port des jeweiligen TCP-Pakets.

Dies könnte verifiziert werden, indem am gegenüber liegenden Switch die eingehenden Rx-Pakete geprüft werden: Sollten hier Pakete verdoppelt eintreffen, dürfte als sicher gelten, dass der jeweils andere Switch den beschriebenen Fehler macht.

212

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Im vorliegenden Fall arbeiteten baugleiche Switches, einander gegenüber stehend, mit denselben Konfigurationen und Firmware-Versionen. So ließ sich schnell bestätigen, dass es sich tatsächlich um Paketverdopplungen handelte. Wenn verdoppelte Pakete des jeweils gegenüber liegenden Switches eintrafen, war jeweils der IP-Wert TTL = 127 zu sehen, nicht jedoch TTL = 128, was besagt, dass der Router-Hop jeweils am gegenüber liegenden Layer-3-Switch erfolgt war; der Switch, der den Mirror-Port stellte, empfing daraufhin die verdoppelten Pakete. Die Screenshots wurden mit EtherPeek erzeugt. Die im Hintergrund sichtbare Paket-Liste weist die TCP Sequence Numbers aus; dadurch wird sichtbar, dass nur zwei Pakete desselben Inhalts vorhanden sind (weil das Paket mit dem Original-Header bzw. mit TTL = 128 wegen des vorangegangenen RouterHops nicht zu sehen ist).

Abbildung 6.37: Die zwei identischen IP-Pakete, die der gegenüber liegende Switch nach dem dort stattgefundenen Router-Hop gesendet hat (Bild 1)

Im Falle der vom gegenüber liegenden Switch gesendeten Doppelpakete ist deutlich zu sehen, dass die IP-Paketnummer mit ID = 47882 identisch ist, ebenso die TCP Sequence Number mit dem Wert 1404278206 (siehe Paketliste im Hintergrund).

6.2.6

Switch-Fehler: Spanning Tree Topology Changes

Quelle: Stuttgart, 2002.

Aus verschiedenen Gründen kann sich ergeben, dass Endgeräte-Ports an Switches am Spanning-Tree teilnehmen (in der Regel sind das historische Gründe). >>> NEW TECH

213

Kapitel 6 • OSI-Schichten 1 und 2

Abbildung 6.38: Die zwei identischen IP-Pakete, die der gegenüber liegende Switch nach dem dort stattgefundenen Router-Hop gesendet hat (Bild 2)

Die Folge ist, dass beim An- und Ausschalten des angeschlossenen Endgeräts (in der Regel Client-PCs) aus Sicht der Spanning-Tree-Log ein Topology Change stattfindet. Dieser Wechsel in der logischen Sternstruktur des Spanning-Tree-Baumes wird vom betroffenen Switch weitergemeldet. Die Wirkung davon ist, dass alle Switches, die davon Kenntnis erlangen, ihre MAC-Tables im Aging-Timer (Verfallsdatum der eingetragenen MAC-Adressen) auf das vorgegebene Forward-Delay zurücksetzen. In der Praxis hat das die Konsequenz, dass viele, wenn nicht alle MAC-Adressen aus den Switch-Tabellen gelöscht und danach erst wieder neu gelernt werden. In dieser Phase des »Learnings« müssen alle Pakete, deren MAC-Empfängeradresse nicht in der Switch-MAC-Tabelle enthalten sind, geflutet werden, bis sie dann »erlernt« und in die MAC-Tabellen aufgenommen wurden. Dieses Verhalten kann toleriert werden, wenn an jedem lokalen LAN-Segment nur ein paar hundert oder wenige tausend Endgeräte angeschlossen sind. Sind jedoch ein paar zehntausend Ethernet-Adapter in einer einzigen, flachen Layer-2-Struktur angeschlossen und somit in einer einzigen Spanning-TreeStruktur, so kann es sporadisch zu erheblichen Flutungen von Ethernet-Frames kommen. Dieses Szenario ist inzwischen selten geworden. Jedoch konnte der Verfasser ein solches noch im Jahr 2002 beobachten; die Zahl der Clients im selben Layer-2-Netzwerk war so hoch, dass es für heutige Verhältnisse schon fast

214

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

nicht mehr glaubhaft erscheint (die Angabe der Client-Anzahl entfällt hier, um keinen Hinweis auf den Kunden zu geben). Das Ganze ist deswegen für die Analyse bedeutsam, weil ggf. im Analyzer sichtbar wird, dass von vielen Teilnehmern zwar Pakete zu sehen sind, die diese gesendet haben, aber keine Pakete, die an diese gerichtet sind. Dies fällt insbesondere dann auf, wenn es sich um TCP-Pakete handelt. In diesem Falle müssen unbedingt die Messdaten auf Spanning-Tree-Meldungen (sog. BPDUs = Bridge Protocol Data Units) untersucht werden. Denn wenn es TCN-Meldungen gibt (TCN = Topology Change Notification), so erklärt sich damit auch das gelegentliche bzw. sporadische Fluten von Unicast-Paketen.

6.2.7

Switch-Fehler: Mirror-Port gibt Pakete falsch aus

Quelle: Stuttgart, 2002.

Das folgende Beispiel stellt nicht wirklich einen Netzwerk-Fehler dar, sondern eine besondere Form von Mess-Fehler. Messungen am Mirror-Port unterliegen immer grundsätzlich der Frage: Sagt der Mirror-Port die Wahrheit? Immerhin werden schon physikalisch defekte Pakete nicht ausgegeben, ggf. auch keine VLAN-Informationen oder auch keine Spanning-Tree-Pakete (je nach Hersteller und Switch-Fabrikat). Hier handelt es sich um eine Paketausgabe am Mirror-Port, die nicht dem tatsächlichen Paketfluss entspricht und insofern dazu einlädt, zu Fehldeutungen zu führen. Es ist immer wieder mal zu beobachten, ... ■

■

... dass Layer-3-Switches bzw. Router Pakete vor und nach dem RoutingHop ausgeben, obwohl nur ein einziger Port gespiegelt wird (nur Rx oder nur Tx), ... dass Layer-3-Switches bzw. Router das FIFO-Prinzip (First In, First Out) bei der Paketausgabe am Mirror-Port nicht einhalten.

Dies zeigt sich in der Analyse an einer Ergebnisausgabe, von der schnell klar ist, dass sie so nicht den Tatsachen der LAN-Kommunikation entsprechen kann (sehr wohl aber den Tatsachen der Paketausgabe am Mirror-Port). Die Abbildung 6.39 zeigt die Ereignisse wie folgt: IP-Pakete sind jeweils zweimal zu sehen, einmal vor dem Routing-Hop, dann nach dem Routing-Hop. (Das jeweilige Paketpaar wird durch die ganz links am Zeilenanfang zu sehende Klammer zusammengehalten bzw. als Paar sichtbar gemacht.) Da der Messpunkt in diesem Fall ein Mirror-Port war und da die Pakete auf der Leitung korrekt sortiert waren (hier nicht zu sehen), ergibt sich daraus, dass der Router die Pakete nicht korrekt am Mirror-Port ausgibt. Im Beispiel der Abbildung ist das Paket Nummer 3817 mit TTL = 127 ausgestattet und Paket Nummer 3818 mit TTL = 128; das widerspricht quasi den Naturgesetzen, denn der Router zählt den TTL-Wert herab, nicht herauf!

>>> NEW TECH

215

Kapitel 6 • OSI-Schichten 1 und 2

Abbildung 6.39: IP-Local-Routing mal anders: Erst TTL = 127, dann TTL = 128 (Mirror-Port-Fehler) (1)

Abbildung 6.40: IP-Local-Routing mal anders: Erst TTL = 127, dann TTL = 128 (Mirror-Port-Fehler) (2)

Die Abbildung 6.40 zeigt das am Beispiel der IP-Pakete Nummer 112 und 114: Beide tragen dieselbe Paketnummer (IP-Paket-ID = 61489), was die Identität beider IP-Pakete beweist – mit Ausnahme der zwei Paramter TTL und

216

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Checksum, da ja durch den Router-Hop der TTL-Wert vermindert und die Prüfsumme neu berechnet wird. Als weiteres, unwandelbares Identitätsmerkmal ist der TCP-Header heranzuziehen. Nun zum Fehler. Das zeitlich zuerst am Mirror-Port ausgegebene Paket Nummer 112 trägt den Wert TTL = 127, das erst danach am Mirror-Port ausgegebene Paket Nummer 114 trägt den Wert TTL = 128 und genau das ist falsch.

Abbildung 6.41: TraceMagic erkennt den Mirror-Port-Fehler und setzt automatisch den Kommentar dazu.

In Abbildung 6.41 ist zu sehen, dass die Event-Log-Ausgabe von TraceMagic das Ereignis mit dem Kommtentar versieht: »Multiple Switch Ports Copied To Mirror-Port!?« Im aktuellen Fall wurde an einem Router ein einzelner Port auf den MirrorPort ausgespiegelt, somit dürften nur die IP-Pakete zu sehen sein, die entweder von außen auf diesen Port treffen (Rx) oder die vom Port nach außen gesendet werden (Tx). Hier jedoch werden einige der Pakete, die geroutet werden, vor und nach Bearbeitung durch die Routing Engine ausgegeben. Das ist schon falsch und der erste Fehler. Der zweite Fehler ist gewissermaßen ein Fehler im Fehler, da das über die Routing Engine laufende IP-Paket in seinen beiden Varianten zeitlich verdreht ausgegeben wird, wie an den TTL-Werten leicht erkannt werden kann: Erst gibt der Mirror-Port die zweite Paket-Inkarnation aus (nach dem RouterHop) und danach erst die erste Paket-Inkarnation (vor dem Router-Hop). Die Switches eines großen Herstellers neigen bisweilen zu einem solchen Verhalten. So sicher es auch ist, dass es sich hier um einen Fehler in der Logik des PortMirrors handelt, man sollte tolerant sein und diese Ereignisse herausrechnen. Sie hindern nicht wirklich an der Analyse, sofern man sie richtig zu deuten weiß. Ein Problem jedoch bleibt grundsätzlich bestehen: Es muss immer mit gewissem Argwohn der Frage nachgegangen werden, ob es sich denn wirklich nur um einen Fehler in der Mirror-Port-Logik handelt und nicht etwa um einen Fehler, der sich auch auf die normalen Funktionen des Layer-3-Switches bzw. Routers auswirkt. Denn es muss ja nicht so sein, dass nur der Mirror-Port davon betroffen wäre.

>>> NEW TECH

217

Kapitel 6 • OSI-Schichten 1 und 2

Die Erfahrung zeigt zwar, dass sich solche Erscheinungen regelmäßig tatsächlich nur auf die Paketausgabe des Mirror-Ports beziehen, trotzdem sollte jedes Mal neu geprüft werden, ob es sich nicht auch um einen allgemeinen Fehler handeln könnte.

6.2.8

Switch-Fehler: Pfadtabellen reichen nicht aus

Quelle: Berlin, 2001.

Eine Messung in Berlin zeigte, wie schwimmend die Grenzen sind zwischen den Bewertungen »Fehler« und »schade, Pech gehabt« oder »dumm gelaufen«. Das klingt zunächst rätselhaft, wird aber schnell nachvollziehbar. Es gab unerklärliche Effekte, die seitens der Anwender so beschrieben wurden, dass teilweise Sitzungen abbrachen, teilweise die Sitzungen langsam wurden (»das Netzwerk ist langsam«), teilweise Sitzungen erst gar nicht zu Stande kamen. Das Unternehmen hatte rund 6.000 Client-PCs über die Stadt verteilt in verschiedenen Niederlassungen. In einer dieser Niederlassungen waren etwa 2.500 Client-PCs aufgebaut. Eine der Messungen wurde an einem der Workgroup-Switches vorgenommen und zwar an einem unkonfigurierten Switch-Port, der somit lediglich als Broadcast-Port arbeitete: Da kein Client-PC aktiv am Port arbeitete, gab der Switch nur – wie üblich – die allgemeinen Broadcasts und Multicasts aus. (Der Analyzer-PC ist im Falle von LANdecoder32 völlig passiv, da der so genannte AccuCapture-Modus die Adapter-Karte nur empfangen, nicht aber senden lässt. Somit kommt kein LAN-Paket vom Analyzer zum Switch, der somit auch keine MAC-Adresse des Analyzers erfährt und folglich auch keine Pakete an ihn adressiert.) Es war schnell festzustellen: Der Broadcast-Port gab sporadisch Unicast-Pakete aus, zum Teil IP-DHCP-Pakete, zum Teil IP-TCP-Pakete. Wie konnte das sein? Hierzu müssen zunächst einmal die mehr oder weniger »normalen« Umstände betrachtet werden, unter denen Unicasts an Broadcasts ausgegeben werden. 1. Ist ein LAN-Paket an eine Empfänger-MAC-Adresse gerichtet, die dem Switch nicht bekannt ist, so ist in diesem Falle der Switch (... die Bridge ...) verpflichtet, das Paket auf allen Ports auszugeben. Dies kann immer wieder mal geschehen. 2. Durch Topology Change im Spanning-Tree wurden die Aging-Timer der Adresseinträge auf das Forward-Delay der Spanning-Tree-Konfiguration herabgesetzt – mit der Folge, dass praktisch alle Adressen aus der Tabelle ungültig und daher neu gelernt werden, was vorübergehend ebenfalls eine Ausgabe von Paketen über alle Ports bedeutet, die an die vorübergehend nicht bekannten MAC-Adressen gerichtet sind.

218

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Wenn man einmal davon ausgeht, dass der zweite Fall nicht gegeben ist, stellt sich die Frage, welche Umstände den scheinbar normalen ersten Fall bewirken können. Unter welchen normalen Umständen sind einem Switch MAC-Adressen nicht bekannt? Dieser Fall würde die Situation voraussetzen, dass ein beliebiger Netzwerk-Teilnehmer ein Paket an einen Empfänger adressiert hätte, der zwar dem Absender bekannt wäre, aber nicht dem aktuellen Switch. Man sehe sich einen Verbindungsaufbau in der TCP/IP-Welt an: Zuerst wird immer ein ARP-Request als Broadcast verschickt mit der Aufforderung an alle Empfänger, sie mögen doch bitte prüfen, ob sie eine bestimmte IP-Adresse ihr eigen nennen und falls ja, möchte derjenige IP-Host doch bitte mit dem ARPReply seine MAC-Adresse bekannt geben. Im ARP-Reply bzw. im MAC-Header des ARP-Replys steht die MAC-Adresse des gesuchten und jetzt antwortenden IP-Hosts. Jetzt könnten alle beteiligten Switches die MAC-Adresse lernen. Aber selbst dann, wenn ARP-Pakete missachtet werden (wenn also MAC-Adressen aus ARP-Paketen ignoriert werden), kommt jetzt vermutlich ein Verbindungsaufbau via TCP: Der erste Kommunikationspartner schickt ein TCP-Paket an den zweiten Partner (TCP-SYN) und dieser antwortet sodann (TCP-SYN-ACK oder TCP-RST). In jedem Falle ist das Gelegenheit genug, die MAC-Adresse des angerufenen Rechners zu lernen. Wird die Verbindung am Ende abgebaut, werden die Signale TCP-FIN und/ oder TCP-RST gesendet (Final, Reset). Jetzt wird es interessant, was die Ausgabe von Unicast-Paketen an BroadcastPorts angeht: Es ist normal, wenn Pakete mit den Signalen TCP-SYN an Broadcast-Ports ausgegeben werden, da bei Sitzungsbeginn die MAC-Adressen dem Switch noch unbekannt sein können – er lernt sie ja gerade erst. Es ist ebenfalls normal (wenngleich unerwünscht), wenn Pakete mit den Signalen TCP-FIN oder TCP-RST an Broadcast-Ports ausgegeben werden, da diesen Signalen möglicherweise eine längere Zeit der Inaktivität voranging, in der zwischen den Dialogpartnern keine Pakete ausgetauscht wurden (auch keine KeepAlive-Pakete, die nur zur Bestätigung des Sitzungserhalts dienen). In dieser Zeit der Inaktivität könnte der Switch die MAC-Adressen schon wieder verworfen haben, da sie ihre Verfallszeit überschritten hätten (Aging-Time). So weit, so gut. Was aber, wenn TCP-Pakete an Broadcast-Ports ausgegeben werden, die weder einem Sitzungsbeginn, noch einem Sitzungsende zuzuordnen sind, sondern ausweislich ihres Inhalts klar einem Vorgang mitten in der Sitzung zuzuordnen sind?

>>> NEW TECH

219

Kapitel 6 • OSI-Schichten 1 und 2

In diesem Falle ist davon auszugehen, dass ein ganz anderes Ereignis das Fluten des Paketes bewirkt haben dürfte (Fluten: Die Ausgabe des Pakets über alle Switch-Ports hinweg). Dieses Ereignis ist der Tabellenüberlauf im Switch oder Router. Es können keine neuen Adressen mehr aufgenommen werden, wenigstens vorüber gehend nicht. Da beim Kunden TCP-Pakete mitten aus laufenden Sitzungen zu sehen waren, kam also der Verdacht auf, es könnte ein solches Flutungs-Szenario sein auf Grund zu kleiner MAC-Tabellen oder des Tabellenüberlaufs. Nun hieß es also, auf weitere Hinweise zu achten, die diesen Verdacht erhärten könnten. Messungen an Mirror-Ports (mit Herausgabe normaler Datenströme) zeigten nun ein weiteres, interessantes Szenario: Es waren ungeheuer viele Peer-to-PeerDialoge zu sehen zwischen verschiedensten PC-Clients und das über den Protokoll-Stapel ETHERNET-LLC-NETBIOS-SMB (= NetBEUI). Die Paar-Matrix, die sich daraus ergab, erstreckte sich über MAC-Adressen der verschiedensten Niederlassungen über das gesamte Stadtgebiet hinweg. Die Überraschung war groß, jedenfalls für den Kunden. Der Verfasser dieser Zeilen stellte sofort die Frage: Warum, bitte schön, wurde bei über 6.000 Client-PCs über das ganze Stadtgebiet hinweg auf Layer 2 ein einziges, flaches Ethernet betrieben, ohne VLANs, ohne Subnetting? Antwort: Weil die Applikation auf NetBIOS/NetBEUI liefe und daher kein Routing möglich sei. Rückfrage: Wieso sei kein Routing möglich? Warum würde nicht NetBIOS-overTCP/IP betrieben (NetBT)? Antwort: Weil die Applikation das nicht unterstütze bzw. weil das programmierende Software-Haus die Applikation noch nicht angepasst hätte und dieses für die nächsten Jahre auch nicht vorhätte. Nun war alles klar: Über 6.000 Rechner arbeiteten in einem einzigen, flachen Layer-2-Netzwerk über NetBIOS. Alle NetBIOS-Clients haben die Pflicht, die Eindeutigkeit und Einmaligkeit sämtlicher anderen NetBIOS-Namen, die sie kennen, zu verifizieren. Das kann im besten Falle über den Master-Browser geschehen, im schlechtesten Falle über permanenten Direktkontakt der NetBIOS-Teilnehmer untereinander, mit der Folge, dass ständig Clients damit beschäftigt sind, Direktkontakt untereinander aufzubauen zwecks Verifikation von Name und Adresse. Das führt zu einer Verkehrs-Matrix, die unter ungünstigen Bedingungen sehr, sehr groß werden kann. Dabei sind weniger etwaige Broadcasts das Problem, sondern NetBEUI-Kontakte, bei denen der eine Client-PC auf den anderen mit einem administrativen Login zugreift und per Systemabfrage die Identität klärt. Für diese Vorgänge werden TCP-SMB-Sitzungen eröffnet, die in den meisten Fällen nach etwa 30 oder 40 Datenpaketen wieder getrennt werden. Der Kunde wollte einwenden: Ja, aber ... es gebe doch »nur« rund 6.000 Clients und die Switches könnten doch bis zu 16.000 MAC-Adressen aufnehmen, wo denn das Problem wäre.

220

>>> NEW TECH

Beispiele für Fehler und ihre Diagnose durch LAN-Analyse

Hier nun kam eine Spezialität der Switches zum Tragen, die unter den Bedingungen eines IP-Netzwerkes vorteilhaft ist, unter den NetBEUI-Bedingungen aber von Nachteil: Diese Eigenart ist, dass nicht eindimensional MAC-Adressen pro Port gelernt werden, sondern Datenpfade von Ende zu Ende; dies ergibt Tabelleneinträge mit jeweils zwei MAC-Adressen (Sender, Empfänger) samt den zugehörigen Port-Nummern. Wenn nun jeder einzelne Client mit nur 10 oder 20 anderen Rechnern Direktkontakt aufnimmt, wird die Zahl der Endezu-Ende-Pfade so groß, dass auch diese Switch-Tabellen sie nicht mehr vollständig aufnehmen bzw. abbilden können. Zum Glück war ein Techniker des Herstellers dabei. Der Techniker blickte in die Tabellenauslastung des Switches und bestätigte: Nichts ging mehr. Alle Möglichkeiten zur Aufnahme von Pfadeinträgen waren erschöpft. Die LAN-Pakete aller weiteren Verbindungen würden geflutet werden – wenigstens dann, wenn der Switch nicht schnell genug alte Tabelleneinträge zu Gunsten neuer Einträge löschen konnte. Somit war klar: Die Flutung von TCP-Unicasts ging zurück auf die Erschöpfung der Adresstabellen und diese Erschöpfung wiederum ging zurück auf eine NetBEUI-Applikation, die zudem maßlos (da falsch programmiert) mit Broadcasts arbeitete und auf diese Weise zusätzlich dafür sorgte, dass die Switches von allen Clients (netzwerkweit, stadtweit) die MAC-Adressen zu sehen bekamen. Dumm war: Der Hersteller dieser Switches bzw. dessen Repräsentanten hatten in einer Vorab-Design-Studie zugesichert, dass diese Switches problemlos in der Lage wären, die vorhandene IT-Architektur abzubilden. Das nennt man »zugesicherte Eigenschaft«. Der Verfasser war bei der anschließenden Elefantenrunde zugegen. Der Deutschland-Chef des Herstellers war samt fünf weiterer Mannen anwesend, mehrere Vertreter des Kunden, zwei oder drei Vertreter des Dienstleisters und Projektführers, ein weiterer Vertreter des Software-Hauses, welches die NetBIOS-Applikation zu verantworten hatte (die ja auch teilweise fehlerhaft programmiert war). Das Klima war so frostig, dass man ein Thermometer hätte aufhängen sollen, um die Kälte festzuhalten. Der Verfasser trug vor, der Techniker des Switch-Herstellers bestätigte. Darauf zog der Deutschland-Chef des Herstellers die Notbremse und bot dem Kunden an, alle (!!) Switches, die übers Stadtgebiet verteilt aufgebaut waren, auszutauschen gegen die größte und leistungsfähigste Switch-Klasse, die der Hersteller zu bieten hatte, um mit dramatisch vergrößerten Adresstabellen schnellstmöglich »Luft« zu verschaffen, bis irgendwann später einmal eine intelligentere Lösung zu finden sein würde. Das bedeutete für den Hersteller einen so großen Verlust, dass alle Erträge aus dem Handel mit diesem Kunden auf Jahre hinaus aufgezehrt waren. Dabei wäre alles im Prinzip so einfach gewesen:

>>> NEW TECH

221

Kapitel 6 • OSI-Schichten 1 und 2

■

■

■

■

Eine ordentliche Ist-Aufnahme hätte ergeben: Die mit NetBIOS (genauer: NetBEUI) auf Layer 2 arbeitenden Clients sorgten für die Erschöpfung der Adresstabellen der Switches. Das hätte zur Folge gehabt, dass man vom Software-Lieferanten die Portierung der Applikation auf TCP/IP bzw. NetBT (NetBIOS-over-TCP/IP) verlangt hätte. Mit Einsatz der NetBT-Applikation wären die Namens- und Adressauflösungen sowie die Verifikation der NetBIOS-Namen über WINS-Server gelaufen. Folge: Kein allgemeines Broadcasting, keine Flutung völlig zufällig vorbeikommender Pakete wegen Erschöpfung der Adresstabellen

Es wäre so einfach gewesen. Man hätte es nur sehen müssen. Das wirft unweigerlich die Frage auf: Warum wurde es nicht gesehen? Nun, diese Frage stellte der Verfasser den Beteiligten auch: Wie wurde denn da bei der Ist-Aufnahme gearbeitet? Antwort: Es wurde mal ein Sniffer ins Netz gehängt und da man keine Fehler festgestellt habe, habe man alles für normal gehalten. So ist das: Da der Sniffer keine ausreichenden Hinweise auf exzessiven NetBIOSVerkehr gab, blieben die Beteiligten quasi blind gegenüber der Gefahr und so liefen alle ins offene Messer. Mit einer klaren Erfassung der Situation wäre das alles nicht geschehen. Als der Verfasser vor den Augen der beteiligten Techniker in weniger als einer Stunde die zum Erkennen nötigen Befunde automatisch über TraceMagic erzeugte und vorlegte, waren Staunen und Verlegenheit vergleichbar groß. Es wäre so einfach gewesen – wenn man es nur gewusst hätte.

HINWEIS Fazit: War das denn nun, wie in der Überschrift angekündigt, ein »Switch-Fehler«? Natürlich nicht – jedenfalls nicht im engeren Sinne, denn die Switches arbeiteten völlig regelkonform. Falsch war, dass die korrekt arbeitenden Switches in der für sie ungeeigneten Umgebung nicht die Performance brachten, die sie hätten bringen müssen.

Entweder war nun also die Umgebung den Switches anzupassen (das wäre nur über eine Portierung der Software auf NetBT gegangen) oder die Switches waren der Umgebung anzupassen. Für den zweiten Weg hat man sich dann entschieden, weil aus Gründen des Zeitdrucks nichts anderes mehr übrig blieb. Eine der Vertragsparteien, in diesem Falle der Hersteller und Lieferant, hat dabei viel Geld verloren.

222

>>> NEW TECH

Kapitel 7 TCP/IP-Grundlagen 7.1 Einführung: Was ist TCP/IP? Mit einer kleinen Geschichte soll der durchaus komplexe Zusammenhang der TCP/IP-Protokolle dargestellt werden. Nehmen Sie sich die Zeit, diese kleine und amüsante Geschichte zu lesen, weil darin die Erklärungen enthalten sind, die sonst so technisch-trocken niedergelegt werden müssten! Bevor Missverständnisse auftauchen, soll darauf hingewiesen werden, dass die Protokolle der TCP/IP-Familie im Auftrage des US-Verteidigungsministeriums (DoD: Department of Defense) entwickelt worden waren. Die folgende Geschichte ist frei erfunden und dient allein der Verdeutlichung der Arbeitsweise von TCP/IP.

7.1.1

Sie erben TCP, Inc. und führen es zum Erfolg

Nehmen Sie an, Sie wären Amerikaner/in, wohnhaft in Berkeley, California, USA, es wäre Anfang der 80er Jahre und Sie hätten von einem reichen Onkel eine mittelgroße Firma geerbt: Transport, Cargo & Parcels (TCP, Inc.). Der Betrieb verdient sein Geld als Spediteur von Postbriefen, Paketen und Warensendungen. Da der Laden schlecht organisiert ist, muss er dringend runderneuert werden. Schon allein die Unzufriedenheit der Kunden wegen ständig abhanden kommender Sendungen macht das nötig. Was würden Sie tun? Nun, vermutlich würden Sie zu allererst für die Zufriedenheit der Kunden sorgen, indem auch alles ankommt, was abgeschickt wird. Sie führen also ein Quittungs- und Überwachungssystem ein: TCP Acknowledgment (ACK) Wer etwas absendet, erhält die vom Empfänger unterschriebene Eingangsquittung zurück. Falls doch noch etwas verloren geht (Glatteis, Schnee, Tornados, ...), ist durch die ständige Durchnummerierung der Pakete immer klar, was fehlt (und was nicht).

>>> NEW TECH

223

Kapitel 7 • TCP/IP-Grundlagen

TCP Window Size Dies ermutigt nun wieder die Absender, verstärkt zu verschicken. Die eintretende Unbedenklichkeit jedoch führt nach und nach dazu, dass Pakete verschickt werden, die nicht angenommen werden können, weil der Empfänger gerade keine Lagerräume dafür frei hat (was in Zeiten von »Just in time«Anlieferungen kontraproduktiv ist). Daraufhin führen Sie für Ihre volumenstarken Kunden den Zusatzdienst der Abnahmegarantie ein, indem vom Absender nur dann Pakete verschickt werden, wenn sie der Empfänger auch einlagern kann. TCP Sliding Window Flow Control Bald stellen Sie fest, dass wegen der nun wieder stark gestiegenen Zufriedenheit der Kunden die Zahl der Warensendungen stark ansteigt. Nun beschweren sich die Empfänger, weil sie zu viele Sendungen erhalten und weil sie so oft zu unterschreiben haben, nämlich je eingehendem Paket genau eine Quittung. Das veranlasst Sie dazu, für alle Pakete, die vom selben Absender kommen, nur noch eine einzige Sammelquittung je Lieferung zu verlangen. TCP Maximum Segment Size (MSS) Zuletzt expandieren Sie noch stark, und nach der ersten Lastwagengeneration (kleine Lasttransporter) führen Sie großvolumige Trucks ein, was den Kunden erlaubt, ihre Waren in größeren Paketen bzw. Kisten zu versenden. Dies führt jedoch in der Unübersichtlichkeit des rapiden Wachstums dazu, dass manchmal Riesenpakete, die ab Versender zunächst von großen Trucks befördert werden, bei der Zustellung auf dem letzten Streckenabschnitt in ältere und kleinere Minitransporter umgeladen werden müssen, weil viele Empfänger draußen auf dem Lande wohnen, wo die neuartigen Trucks nicht passieren können. Oft müssen Pakete in mehrere Teile zerschnitten werden, um in Kleintransportern einzeln über den letzten Zufahrtsweg zugestellt zu werden. Das allein ist schon unangenehm – für Sie und Ihre Kunden. Da Sie aber daran nicht gedacht und leichtsinnig die alten, kleinen Transporter abgeschafft haben, können manchmal in ländlichen Gegenden oft Pakete nicht zugestellt werden: die großen Trucks können die Schotterwege nicht passieren, und die kleinen Transporter müssen erst wieder nach und nach beschafft werden, wo der Ausbau der Straßen und Wege nicht im erforderlichen Ausmaß voranschreitet. Aber selbst dann bleibt das Zerschneiden von Paketen, die zu groß sind für die Kleintransporter, eine lästige Arbeit. Also führen Sie zuletzt noch ein, dass beim Abfragen der Annahmebereitschaft des Empfängers zugleich auch geprüft wird, über welche Zufahrt der Empfänger verfügt und ob alle Teilstrecken über ausreichend großvolumige Lkw’s oder eben kleine Transporter verfügen. So kann dann schon der Absender die Ware in die richtigen Pakete füllen: große oder kleine, je nach Fahrzeug: Groß- oder Kleintransporter.

224

>>> NEW TECH

Einführung: Was ist TCP/IP?

TCP und UDP Kunden, die auf alle diese Mehrwertdienste keinen Wert legen, werden mit simpler Auslieferung ohne jede Kontrolle bedient; dieser Service erhält den Produktnamen Unattended Delivery Progra (UDP, siehe unten). Jetzt, da dies geschafft ist, blüht Ihr Unternehmen, und Sie freuen sich über Ihren Erfolg.

7.1.2

Einrichtung von UDP wegen des Kostendrucks

Inzwischen hat sich herausgestellt, dass die hervorragenden Leistungen von Transport, Cargo & Parcels zwar ungeschlagen sind, aber durchaus nicht von jedem Kunden benötigt werden. Das ausgefeilte System, mit dem die zuverlässige Zustellung auch großer Mengen garantiert wird, ist oft auch hinderlich. Dies gilt beispielsweise bei belanglosen Werbesendungen, wo es wichtiger ist, von einem Tag auf den anderen Tausende versenden zu können, als auf die wenigen zu achten, die nicht ankommen. Auch die Zusendungen von kleinen Postkarten mit Adressabfragen werden von TCP mit einem viel zu großen Aufwand verarbeitet: Geht es doch großen Katalog-Versendern nur darum, dann und wann die Adresse der Kunden und Interessenten zu überprüfen, indem diese zur Rücksendung einer Postkarte angeregt werden. Ob hier nun jede ankommt, war im Laufe der Zeit unwichtig; wichtig ist, dass der Dienst in der überwiegenden Vielzahl gut läuft und ansonsten unkompliziert ist; der aufwendige TCP-Service aber lohnt sich für diese kleinen Adressabfragen nicht. So gründen Sie also das Unattended Delivery Program (UDP), um auch Versendungen mit geringerem Sicherheitsbedarf bedienen zu können; dies könnte gut mit »unbeaufsichtigte Auslieferung« übersetzt werden. »Adressaufkleber und Prüfzeichen aufs Paket kleben, abgeben, fertig!« Dieser Slogan leuchtet Ihren Kunden ein, die fortan für einfache Versendungen UDP in Anspruch nehmen.

7.1.3

Sie expandieren und fusionieren mit der IP, Inc.

Bei der wachsenden Nachfrage überregional tätiger Kunden kommt es Ihnen gerade recht, dass ein befreundeter Fuhrunternehmer, der mit seiner Firma International Parcels (IP, Inc.) auf Langstreckentransporte spezialisiert ist, Ihnen Folgendes vorschlägt: Sie hätten das ausgereiftere Logistik-System, er hätte das sogar weltweit arbeitende Spediteur-System. Sie erkennen die großartigen Chancen und fusionieren zur TCP/IP, Inc.. Was bringt IP, Inc. mit in die Firmenehe?

>>> NEW TECH

225

Kapitel 7 • TCP/IP-Grundlagen

IP-Adressen Ihr neuer Partner hatte schon frühzeitig die ganze Welt in Zustellregionen eingeteilt, sehr ähnlich den alten, vierstelligen Postleitzahlen der Bundesrepublik Deutschland, wo es damals ja auch noch hieß: »5000 Köln 1«. Auch die »IP, Inc.« hatte früh vierstellige PLZ (= Paket-Leit-Zahlen) eingeführt, und der einzige Unterschied zu den deutschen PLZ war, dass die Ziffern durch Punkte getrennt wurden, da sie nicht 10-stellig (0-9) arbeiteten, sondern 255stellig, was einen riesigen Nummernraum erschloss. So konnte Köln beispielsweise adressiert werden mit: 192.175.68.64. Jeder, der die aktuelle PLZ-Tabelle hatte, konnte nachlesen, dass dies für »Köln« stand (oder für welche Stadt auch immer). Ja, man konnte sogar mit der Nummer schon einen einzelnen Empfänger bezeichnen – eine Möglichkeit, die im deutschen PLZ-System erst mit Einführung der 5-stelligen PLZ möglich wurde. Wie auch immer: Die Neuerung der IP, Inc. war so bahnbrechend, dass man allerorts nur noch von den berühmten »IP-Adressen« sprach. Und bald interessierten sich immer mehr Teilnehmer für dieses Paketsystem, weil sie Irrläufer im Transportsystem praktisch ausschloss. IP Time To Live (TTL) Um aber trotzdem gegenüber Irrläufern eine Sicherheit zu haben, wurde jedes Paket mit einer maximalen Umlaufdauer versehen: Fand ein Paket seinen Empfänger nicht, und war es zu lange unterwegs, und belastete es also letztlich nur noch die Frachtkapazitäten, so wurde es irgendwann vernichtet – allerdings mit der begleitenden Maßnahme, dass dann eine Rückmeldung an den Absender erfolgte, dass keine Zustellung möglich war wegen endlosen Kreisens des Pakets im Speditionsbereich von IP. Hierzu wurde eigens die International Cargo Management Platform (ICMP) geschaffen; sie wird weiter unten beschrieben. IP Fragmentation Den Leuten von IP, Inc. war bei der Fusion mit TCP, Inc. aufgefallen, dass es da dieses Zustellungsproblem gab, wenn große Pakete zerschnitten, auf viele kleine Pakete verteilt und auf Kleintransportern befördert werden mussten. Ihnen war aufgefallen, dass die TCP-Leute danach heftige Probleme hatten, auf dem Betriebshof des Empfängers die kleinen Minipakete wieder zum ursprünglichen Großpaket zusammenzusetzen. Manches Mal nahm der Inhalt Schaden, und manches Mal dauerte das so lange, dass der Empfänger darüber ungehalten wurde. Die IP-Leute fanden hier Abhilfe: Sie erweiterten das Schema ihrer Adressnummern so, dass nun sogar ganz leicht fragmentiert werden konnte (»fragmentieren« war jetzt das Wort für »zerlegen«).

226

>>> NEW TECH

Einführung: Was ist TCP/IP?

Sie gaben jedem Auslieferungsfahrer ein kleines Kopiergerät mit; beim Fragmentieren wird seither auf jedes Fragment eine Kopie des ursprünglichen Frachtzettels geklebt, so dass alle Adressen auch auf den Fragmenten vorhanden sind; zusätzlich werden die Fragmente in ihrer Reihenfolge dadurch gekennzeichnet, dass die Position des Schnitts jeweils kenntlich wurde, also etwa: »Fragment mit der Schnittstelle bei 132 cm ab Beginn des Originalpaketes«. Wenn ganz ausnahmsweise dann doch einmal etwas schief läuft, sorgt schon ICMP dafür, dass der Absender davon Kenntnis erhält. IP Packet ID (Fragment ID) Manchmal kam es vor, dass mehrere Großpakete an denselben Empfänger zur selben Zeit unterwegs waren, so dass mehrere Originalpakete zu zerlegen und wieder zusammen zu setzen waren. Da gab es manchmal Kuddelmuddel: Welches Fragment (welches Mini-Paket) gehörte nun mit welchem anderen zu welchem Originalpaket zusammen? Damit der Mechanismus des Kopierens des Frachtzettels auch wirklich keine Verwechslungen mehr zuließ, wurde nun dafür gesorgt, dass der Absender seinerseits schon jedes Paket mit einer eindeutigen, fortlaufenden Nummer versah. Seither können auch die Fragmente sauber zugeordnet werden; und sollte doch einmal etwas falsch laufen, kann per ICMP dem Absender genau gesagt werden, mit welcher seiner Frachtsendungen etwas nicht stimmt. IP Fragmentation Control (Fragmentation Flags) Nun waren sich die IP-Leute im Klaren darüber, dass manche Absender dann doch lieber darauf verzichten wollten, sich auf das verbleibende Restrisiko des Fragmentierens einzulassen. Also gab man den Absendern die Möglichkeit, selber zu steuern, ob die Fragmentierung stattfindet oder nicht. Diese Art der Steuerung ist bis heute ganz einfach: Auf dem Adressaufkleber sind seither zwei Felder zum Ankreuzen. Das erste Kreuz (wenn es denn gesetzt wird) ist ein Versenderzeichen und verbietet jedes Fragmentieren. Ist aber Fragmentieren nötig, so gibt es mit ICMP eine Rückmeldung an den Absender, und der kann sich dann etwas Neues ausdenken. Das zweite Kreuz (wenn es denn gesetzt wird) ist ein Spediteurszeichen und wird in den Kopien der Adresszettel gesetzt, die nach einem Zerlegen auf die Fragmente geklebt werden. Dadurch wird einfach gekennzeichnet, wann das letzte Fragment einer langen Reihe gegeben ist, damit die Auslieferungsfahrer nicht unnötige Zeit damit verlieren, auf weitere Fragmente (Mini-Pakete) bei sich im Transporterfahrzeug zu suchen.

>>> NEW TECH

227

Kapitel 7 • TCP/IP-Grundlagen

IP Length Und damit die letzten Zweifel über die Handhabung und über das Wiederzusammensetzen ausgeräumt werden können, wurde dem Adressaufkleber zusätzlich ein Feld gegeben, in dem die Länge des Paketes ab Versender eingetragen wird. Die Angabe der Länge reicht, da Höhe und Breite genormt sind und darum nicht weiter angegeben werden müssen.

7.1.4

ICMP meldet Störungen

Die IP-Leute waren wie die TCP-Leute frühzeitig auf die Idee gekommen, den Kunden die garantierte Auslieferung der Pakete zuzusagen. Daher wurde schon früh jedes Paket standardweise als eingeschriebener Brief behandelt. Alle Niederlassungen (Lager- und Verteilsysteme) wurden so ausgerüstet, dass der Verlust und/oder die Unzustellbarkeit eines Paketes sofort entdeckt und auch unweigerlich an den Absender gemeldet wurde. Dieses geniale System hatte einen Namen: International Cargo Management Platform (ICMP). Die IP, Inc. war seinerzeit durch dieses System der garantierten Auslieferung bzw. Rückmeldung so berühmt geworden, dass die Fusion mit der gleichfalls weithin anerkannten TCP, Inc. zur TCP/IP, Inc. die Welt aufhorchen ließ. ICMP: Time Exceeded (TTL Expired) Ein Paket musste vernichtet werden, weil seine höchst zulässige Transportzeit abgelaufen war? Kein Problem, ICMP meldet das. ICMP: Time Exceeded (Reassembly Timer Expired) Ein Fragment war wohl verloren gegangen, weil auch nach längerem Warten das fehlende Minipaket nicht gefunden und somit das originale Großpaket nicht zusammengesetzt werden konnte, sondern sogar verworfen werden musste? Kein Problem, ICMP meldet das. ICMP: Network Unreachable Der Empfänger konnte nicht ermittelt werden, weil die Adresse nicht eindeutig oder sogar falsch war? Auch das meldet ICMP. ICMP: Host Unreachable Der Empfänger kann zwar aus der IP-Adresse ermittelt werden, ist aber nicht zu Hause und kann das Paket nicht annehmen? Kein Problem für ICMP.

228

>>> NEW TECH

Einführung: Was ist TCP/IP?

ICMP: Service Unavailable Beim Empfänger ist zwar der Pförtner da, aber die Abteilung wurde aufgelöst (oder ist beim Betriebsfest)? Auch das meldet ICMP. ICMP: Redirect Der Empfänger ist verzogen? Oder es gibt einen kürzeren Weg als den vorgesehenen Standardweg? Kein Problem: Dann meldet, wer es besser weiß, per ICMP die gültige Adresse bzw. den gültigen Weg. (»Redirect«: Umleiten.) ICMP: Source Quench Ein Absender verstopft mit einer wahnwitzigen Menge das Transportsystem von TCP/IP, und es gibt schon nicht mehr genügend Auslieferfahrzeuge, um des Ansturms Herr zu werden? Oder der Empfänger kann nichts mehr annehmen, weil schon der Betriebshof voll steht? Dann meldet ICMP zurück, dass doch bitte weniger gesendet werden möge, damit der Stau abgearbeitet werden kann. Ein witziger IP-Logistiker ließ sich die Bezeichnung »Source Quench« einfallen, um damit auszudrücken, dass der Absender (»Source«) den Transportdienst oder den Empfänger erdrückt (»Quench«). ICMP: Echo Request/Reply Zu guter Letzt gab man dem Absender die Möglichkeit, sich der Arbeitsfähigkeit des Frachtdienstes zu vergewissern, indem kleine Testpäckchen zum Empfänger geschickt werden können mit der Bitte um Rücksendung – einfach so. Dieses kleine »Päckchen-Ping-Pong-Spiel« hatte seit seiner Einführung ungeahnte Auswirkungen: Es machte TCP/IP, Inc. mit einem Schlage weltberühmt. Selbst Kunden, die eigentlich niemals ernsthaft Pakete zu verschicken hatten, begannen, die Dienste von TCP/IP, Inc. in Anspruch zu nehmen, um mit einem simplen »Ping«-Päckchen (so heißt es seitdem) die Erreichbarkeit von-wemauch-immer auszutesten. Manchmal geht der Erfolg seltsame Wege.

7.1.5

ARP und DNS für die richtige Adresse

Manchmal müssen selbst in der modernen TCP-IP-Welt noch ganz banale Probleme gelöst werden. Darunter fällt beispielsweise die Frage: Welche Straße und welche Hausnummer verbirgt sich eigentlich hinter der so berühmten IPAdresse? Jeder Auslieferungsfahrer fluchte in den alten Tagen täglich mehrfach, weil ihm das die Schwierigkeit bereitete, in einer Tabelle nachsehen zu müssen. Doch die IP-Leute lösten auch das Problem. Wenn der Auslieferfahrer zu einer IP-Adresse die Verkehrs-Adresse (Straße, Hausnummer) nicht kennt, fragt er sie mit ARP ab.

>>> NEW TECH

229

Kapitel 7 • TCP/IP-Grundlagen

Manchmal wissen die Absender nicht, welche IP-Adresse sie auf das Paket schreiben sollen; aber den Namen des Empfängers kennen sie. Dann können sie zum Namen die richtige IP-Adresse mittels DNS abfragen.

7.1.6

SNMP+RMON – Überwachung in Echtzeit

So weit, so gut. Ihre TCP/IP Company war erfolgreich und hatte nunmehr ein Transportnetz, das wohl einmalig war und ist. Am Ende der Geschichte (das Zeitalter der elektronischen Datenübermittlung war gerade gekommen) überlegten Sie sich mit Ihrem Partner, wie schön das doch für Ihre Kunden wäre, wenn diese jederzeit am Bildschirm nachvollziehen könnten (und zwar in Echtzeit!), wo sich gerade ihr Paket befindet, und ob das Verteilzentrum, in dem es gerade lagert, korrekt arbeitet, oder ob die Transportverbindung zwischen zwei Stützpunkten auch wirklich intakt ist. Hierzu führen Sie schlussendlich noch das vollends hitverdächtige, neue System zur Überwachung ihres Transport- und Logistik-Systems ein: »See Now More Packets« (SNMP) Und nun ist Ihr Weg an die Weltspitze nicht mehr aufzuhalten. Und als Sie SNMP noch mit RMON ergänzen ... »Rapid Misson Overview Now!« (RMON) ... ist klar: TCP/IP, Inc. gehört die Welt der Pakete und Päckchen!

7.1.7

Des Rätsels Lösung

Und so wurde es dann Wirklichkeit, unser als Märchen getarntes Rätsel: In Berkeley, Californa, USA, wurden in den Jahren 1981-83 die heute verwendeten Versionen von TCP/IP programmiert; bis Ende der 80er Jahre kamen noch ARP und SNMP dazu, in den 90er Jahren dann noch RMON. So arbeitet das Internet – bis heute.

7.2 Die wichtigsten Protokolle der TCP/IP-Familie im Überblick Die eben in Form der kleinen Geschichte vorgetragenen Zusammenhänge müssen nun noch in die Welt der Protokolle übertragen werden. Es folgt eine Übersicht, um die Protokollstrukturen und ihre Parameter zum schnellen Nachschlagen in einem einzigen Abschnitt zu haben. Fehlersuche und Fehlerbehebung werden dann in einem Abschnitt weiter hinten dargestellt.

230

>>> NEW TECH

Die wichtigsten Protokolle der TCP/IP-Familie im Überblick

Abkürzung

Protokoll

ARP/RARP

Address Resolution Protocol/Reverse ARP

IP

Internet Protocol

ICMP

Internet Control Message Protocol

TCP

Transmission Control Protocol

UDP

User Datagram Protocol

BOOTP

Bootstrap Protocol

DHCP

Dynamic Host Configuration Protocol

DNS

Domain Name Service

WINS

Windows Internet Name Service

SNMP

Simple Network Management Protocol

RMON

Remote (Network) MONitoring

Tabelle 7.1:

7.2.1

Die wichtigsten Protokolle des Internet im Überblick

Fundstellen in der WinNT Registry

Folgende Schlüssel innerhalb der WinNT Registry beschäftigen sich mit der TCP/IP-Kommunikation (ohne Garantie der Vollständigkeit): Microsoft Windows NT Registry Keys: TCP/IP HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\.. ..\ServiceProvider\Order ..\Services\Tcpip\ServiceProvider HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\.. ..\AdapterName#\Parameters\Tcpip ..\Afd\Parameters ..\DHCP\Parameters\Options\Option# ..\DhcpServer\Parameters ..\DNS\Parameters ..\DNS\Zones\Zone name ..\InetInfo\Parameters ..\IpRip\Parameters ..\NetBT\Adapters\AdapterName ..\NetBT\Parameters ..\Tcpip\Parameters ..\Tcpip\Parameters\PersistentRoutes ..\Tcpip\Parameters\Winsock ..\W3SVC\Parameters ..\WinSock\Parameters Tabelle 7.2:

WinNT Registry Keys – TCP/IP

>>> NEW TECH

231

Kapitel 7 • TCP/IP-Grundlagen

7.2.2

ARP – Address Resolution Protocol

Mit ARP wird nach der MAC-Adresse von IP-Teilnehmern gesucht, die als Gegenstelle angesprochen werden sollen. Mit RARP (Reverse ARP) wird die eigene IP-Adresse bei einem RARP-Server nachgefragt (gedacht für Diskless Workstations). Der ARP-Header hat folgenden Aufbau:

Abbildung 7.1: Der ARP-Header (PCI) ARP Parameter

Länge

Bedeutung

ARP Hardware Type

16 Bit

Kennzeichnung des Netzwerk-Typs 1 = Ethernet 10 Mbps 2 = Experimental Ethernet 3 = Amateur-Radio AX.25 4 = Proteon PROnet Token-Ring 5 = CHAOSnet 6 = IEEE 802.x LANs 7 = ARCnet

ARP Protocol Type

16 Bit

Protokoll-Kennung; es werden die bekannten EtherType-IDs verwendet.

ARP Hardware Length

8 Bit

Länge der Hardware-Adressen (MAC)

ARP Software Length

8 Bit

Länge der Software-Adressen (IP)

Tabelle 7.3: 232

ARP – Übersicht zu den Parametern des Protokoll-Headers >>> NEW TECH

Die wichtigsten Protokolle der TCP/IP-Familie im Überblick

ARP Parameter

Länge

ARP Operation Code

16 Bit

Bedeutung Kennzeichnung der ARP-Funktion: 0 = ARP Request 1 = ARP Reply 2 = RARP Request 3 = RARP Reply

Hardware Source Address

6 Byte

MAC-Adresse des Senders

Software Source Address

4 Byte

IP-Adresse des Senders

Hardware Destin. Address

6 Byte

MAC-Adresse des Empfängers

Software Destin. Address

4 Byte

IP-Adresse des Empfängers

Tabelle 7.3:

7.2.3

ARP – Übersicht zu den Parametern des Protokoll-Headers (Forts.)

IP – Internet Protocol

IP ist das Vermittlungs- bzw. Routing-Protokoll der TCP/IP-Familie. Es arbeitet vermittlungslos und ungesichert. Der IP-Header hat folgenden Aufbau:

Abbildung 7.2: Der IPv4-Header (PCI)

>>> NEW TECH

233

Kapitel 7 • TCP/IP-Grundlagen

IPv4 Parameter

Länge

IP Version

4 Bit

Bedeutung Versionsnummer. Allgemein gebräuchlich ist die Anfang der 80er Jahre eingeführte Version 4. IPv6 wird bereits im Internet von den Dienstleistern verwendet.

IP Header Length

4 Bit

Länge des IP-Headers. Da der IP-Header länger sein kann als die üblichen 20 Bytes, muss bei Vorhandensein sog. »IP Options« die Gesamtlänge kenntlich gemacht werden, damit die Grenze zu TCP oder UDP dem Empfänger gegenüber deutlich wird.

IP Type of Service (ToS)

8 Bit

Heute würde man diese ToS-Parameter eher als »QoS«-Parameter (Quality of Service) bezeichnen: Precedence Normal/Low Delay Normal/High Throughput Normal/High Reliability

IP Total Length

16 Bit

Die gesamte Länge des IP-Paketes unter Einschluss aller nachfolgenden Daten. Beispiel: Der Längenwert könnte die Anzahl der Oktette von IP+TCP+TELNET enthalten.

IP Identification

16 Bit

Ein eindeutiger Paketzähler, auch »IP Fragment ID« oder »IP Packet ID« genannt. Jeder IP-Treiber hat den Wert dieser ID bei jedem IP-Paket um 1 zu erhöhen. (Microsoft hat hier traditionell einen Fehler und addiert bei Windows 3.x, Windows 9.4 und NT ganze 255=0x0100 hinzu.)

IP Fragmentation Flags

3 Bit

Diese kleinen Markierungen dienen der Steuerung der sog. IP-Fragmentierung: May/Don’t Fragment Last/More Fragments

IP Fragment Offset

Tabelle 7.4:

234

13 Bit

Im Falle des Zerlegens von IP-Paketen in Fragmente besagt der Offset-Wert, welche Startposition das aktuelle Fragment im Originalpaket hat(te).

IPv4 – Übersicht zu den Parametern des Protokoll-Headers

>>> NEW TECH

Die wichtigsten Protokolle der TCP/IP-Familie im Überblick

IPv4 Parameter

Länge

Bedeutung

IP Time To Live (TTL)

8 Bit

Dieser Wert stellt einen sog. Hop Credit dar, der angibt, wie viele Router das IPPaket überqueren darf. Da jeder Router den Wert um mindestens 1 bei der Querung vermindert, und da der letzte Router das IP-Paket verwirft (bei dem TTL=0 eintritt), ist die »Lebenszeit« des Paketes tatsächlich begrenzt.

IP Protocol [ID]

8 Bit

Diese Protokollkennung gibt an, welches Protokoll innerhalb des IP-Paketes als nächstes folgt, z.B. TCP oder UDP.

IP Header Checksum

16 Bit

Prüfsumme über den IP-Header (nicht über die Daten innerhalb des IP-Pakets). Die Prüfsumme wird von jedem Router neu berechnet, da durch jeden Router der TTL-Wert vermindert und dadurch die Prüfsumme ungültig wird.

IP Source Address

32 Bit

IP-Absenderadresse.

IP Destination Address

32 Bit

IP-Empfängeradresse.

IP Options

(variabel)

Der IP-Header kann die Standardlänge von 20 Oktetten überschreiten, wenn Optionen verwendet werden. Eine der bekanntesten Optionen ist das sog. Source Routing bzw. Record Route, das die Router veranlasst, ihre IP-Adresse ins IP-Paket zu schreiben, was dem Empfänger den Weg sichtbar macht.

IP Padding

(variabel)

Falls Optionen verwendet werden, muss sichergestellt sein, dass der gesamte IPHeader ein ganzzahliges Vielfaches von 32 Bit darstellt. Ergeben die Optionen (falls vorhanden) nicht ihrerseits ein Vielfaches von 32 Bit, so muss der Header mit Stopf-Bits bis auf diesen Wert verlängert werden.

Tabelle 7.4:

7.2.4

IPv4 – Übersicht zu den Parametern des Protokoll-Headers (Forts.)

ICMP – Internet Control Message Protocol

ICMP wird verwendet, wann immer Fehler in der Auslieferung von IP-Paketen auftreten; die Fehler können bei Routern oder bei den Endgeräten auftreten; sie können bei IP, TCP oder UDP zu suchen sein: In (fast) jedem denkbaren Fall wird mittels ICMP dem ursprünglichen Absender des betroffenen IP-Paketes eine Rückmeldung gegeben, die Aufschluss über Art des Fehlers und ggf. über die getroffene Maßnahme gibt. >>> NEW TECH

235

Kapitel 7 • TCP/IP-Grundlagen

Der ICMP-Header hat folgenden Aufbau:

Abbildung 7.3: Der ICMP-Header (PCI) ICMP Parameter

Länge

Bedeutung

ICMP Type

8 Bit

Angabe der Hauptfunktion der ICMP-Nachricht

ICMP Code

8 Bit

Angaben der jeweiligen Unterfunktion der ICMP-Nachricht

ICMP Checksum

16 Bit

Prüfsumme über den ICMP-Header

ICMP Operation

4 Byte

Zusätzliche Angaben in Abhängigkeit zu den Angaben im Feld Type. In vielen Fällen bleibt das Feld Operation ungenutzt und somit leer.

ICMP Message

28 Byte

Zusätzliche Angaben in Abhängigkeit zu den Angaben im Feld Type. In vielen Fällen bleibt das Feld Message ungenutzt und somit leer. Im Falle von Echo Reply/Request (Ping) werden beliebige Testdaten im Feld Message übermittelt.

Tabelle 7.5:

ICMP – Übersicht zu den Parametern des Protokoll-Headers

ICMP ist ein sehr variables Protokoll; dies entspricht der Vielzahl von Fehlern in der Übermittlung von IP-Paketen, die mit ICMP ggf. zu melden sind.

236

>>> NEW TECH

Die wichtigsten Protokolle der TCP/IP-Familie im Überblick

Die folgende Tabelle zeigt die verschiedenen ICMP-Typen: ICMP Type

Bezeichnung

Bedeutung

00

Echo Reply

Antwort auf Echo Request

03

Destination Unreachable

Empfänger nicht erreichbar

04

Source Quench

Überlastung durch den Sender

05

Redirect

Umleitung (über andere Router)

08

Echo Request

Anforderung auf Echo Reply

09

Router Advertisement Message

Bekanntgabe eines Routers

10

Router Solicitation Message

Suche nach einem Router

11

Time Exceeded

Zeit abgelaufen (u.a. TTL)

12

Parameter Problem

Falsche ICMP-Angaben

13

Timestamp Request

Umlaufzeit-Anfrage

14

Timestamp Reply

Umlaufzeit-Antwort

15

Information Request

Information-Anfrage

16

Information Reply

Information-Antwort

A1

Address Format Request

Subnet-Mask-Anfrage

A2

Address Format Reply

Subnet-Mask-Antwort

Tabelle 7.6:

ICMP Type-Werte

Die verschiedenen Type-Varianten werden noch weiter untergliedert durch eine Reihe von Code-Werten, die Unterfunktionen darstellen. Type

Code

00

Bedeutung

Absender

Echo Reply/Antwort 0

(Code ist ohne Bedeutung)

03

Host, Router

Destination Unreachable/Unzustellbar 0

Netz ist nicht erreichbar

Router

1

Rechner ist nicht erreichbar

Router

2

Protokoll beim Rechner nicht erreichbar

Host

3

Port ist beim Rechner nicht erreichbar

Host

4

Fragmentierung nötig, aber nicht gestattet

Router

5

Source Route nicht erreichbar

Router

04

Source Quench/Überlastung durch Sender 0

Tabelle 7.7:

Datagramm konnte nicht bearbeitet werden

Host, Router

ICMP Code-Werte

>>> NEW TECH

237

Kapitel 7 • TCP/IP-Grundlagen

Type

Code

05

Absender

Redirect/Umleitung der Datagramme ... 0

... zu einem bestimmten IP-Netz

Router

1

... zu einem bestimmten Host

Router

2

... für einen bestimmten Service- und Netz-Typ

Router

3

... für einen bestimmten Service-Typ und Host

Router

08

Echo Request/Anforderung 0

09

(ohne Bedeutung)

Host, Router

Router Advertisement Message 0

10

Bekanntmachung eines Routers

Router

Router Solicitation Message 0

Aufforderung an Router, sich zu melden

0

TTL auf 0 gefallen/IP-Paket wurde verworfen

Router

1

Reassembly-Timer abgelaufen (Fragmentation)

Router

11

Host, Router

Time Exceeded/Zeitüberschreitung

12

Parameter Problem/falsche ICMP-Angaben 0

13

Pointer im ICMP-Header fehlerhaft

Host, Router

Timestamp Request/Umlaufzeit-Anforderung 0

14

(ohne Bedeutung)

Host, Router

Timestamp Reply/Umlaufzeit-Antwort 0

15

(ohne Bedeutung)

Host, Router

Information Request/Information-Anfrage 0

16

(ohne Bedeutung)

Host, Router

Information Reply/Information-Antwort 0

A1

(ohne Bedeutung)

Host, Router

Address Format Request/Subnet-Mask-Anfrage 0

A2

(ohne Bedeutung)

Host, Router

Address Format Reply/Subnet-Mask-Antwort 0

Tabelle 7.7:

238

Bedeutung

Code-Wert entspricht Zahl der Subnet-MaskBits

Host, Router

ICMP Code-Werte (Forts.)

>>> NEW TECH

Die wichtigsten Protokolle der TCP/IP-Familie im Überblick

Die Analyse von IP-Netzwerken arbeitet stark mit der Auswertung von ICMPMeldungen. Hierzu sei auf die nachfolgenden Abschnitte verwiesen.

7.2.5

TCP – Transmission Control Protocol

TCP ist (im Gegensatz zu UDP) ein verbindungsorientiert und mit Empfangsquittung arbeitendes Transportprotokoll, das mit den Mitteln von Data Flow Control den Datenfluss gegenüber Störungen im Netz und in den Endgeräten absichert. Der TCP-Header hat folgenden Aufbau:

Abbildung 7.4: Der TCP-Header (PCI) TCP Parameter

Länge

Bedeutung

TCP Source Port

16 Bit

Prozesskennung beim Absender

TCP Destination Port

16 Bit

Prozesskennung beim Empfänger

TCP Sequence Number

32 Bit

Tabelle 7.8:

Startposition im Byte-Strom des Absenders. Der Absender gibt an, ab welchem Offset der zu sendenden Datenmenge dieses Paket beginnt.

TCP – Übersicht zu den Parametern des Protokoll-Headers

>>> NEW TECH

239

Kapitel 7 • TCP/IP-Grundlagen

TCP Parameter

Länge

Bedeutung

TCP Acknowledge Number

32 Bit

Positionsbestätigung des Empfängers und Sendeaufforderung. Der Empfänger bestätigt, bis zu welchem Offset bzw. bis zu welcher Byte-Position er Daten lückenlos erhalten hat; das entspricht der TCP Sequence Number der Gegenstelle zuzüglich der von ihr erhaltenen Datenmenge. Zu diesem Empfangs-Offset wird der Wert 1 gezählt, um mit der TCP Acknowledgement Number anzuzeigen, ab welcher Byte-Position (ab welcher TCP Sequence Number) die Gegenstelle die Übertragung fortsetzen soll.

TCP Data Offset

4 Bit

Zeiger auf den Beginn des Datenteils. Entspricht der Länge des TCP-Headers. Wird als Vielfaches von je 32 Bit gerechnet (siehe auch: IP Header Length). Den vier Data Offset-Bits folgen sechs weitere, nicht belegte Bits.

TCP Control Flags

6 Bit

Funktionsanzeiger: URG – Urgent Pointer vorhanden! ACK – Acknowledge Number lesen! PSH – Daten vorhanden für Destin.-Port! RST – Verbindungsende wird angezeigt SYN – Verbindungsaufbau wird angezeigt FIN – Ende des Datenstroms wird angezeigt

TCP Window (Size)

16 Bit

Größe des reservierten Empfangspuffers. Die Gegenstelle darf bis zum Erreichen dieser Byte-Menge senden, ohne einzelne Quittung abwarten zu müssen. Eine Window-Size von 0 verbietet der Gegenstelle jede Übertragung von Nutzdaten, bis wieder freier Puffer gemeldet wird.

TCP Checksum

16 Bit

Prüfsumme über TCP-Header und Daten.

TCP Urgent Pointer

16 Bit

Zeiger auf vorrangige Daten im Paket.

TCP Options

(variabel)

Verlängerung des sonst 20 Oktette langen TCP-Headers um weitere Angaben. Die einzige TCP-Option, die bis heute verwendet wird, ist die Bekanntgabe der jeweils lokal maximal möglichen Paket-Größe (TCP Maximum Segment Size), die wiederum davon abhängt, ob mit Ethernet oder Token-Ring (oder anderen Topologien) gearbeitet wird.

Tabelle 7.8:

240

TCP – Übersicht zu den Parametern des Protokoll-Headers (Forts.)

>>> NEW TECH

Vorgehensweise

Eine ausführliche Erklärung der Wirkungsweise von TCP und seiner Parameter ist in Abschnitt 7.8.1 zu finden.

7.2.6

UDP – User Datagram Protocol

UDP ist (im Gegensatz zu TCP) ein verbindungslos und ohne Empfangsquittung arbeitendes Transportprotokoll. Der UDP-Header hat folgenden Aufbau:

Abbildung 7.5: Der UDP-Header (PCI) UDP Parameter

Länge

Bedeutung

UDP Source Port

16 Bit

Prozesskennung beim Absender

UDP Destination Port

16 Bit

Prozesskennung beim Empfängers

UDP Length

16 Bit

Länge des UDP-Headers sowie der Daten

UDP Checksum

16 Bit

Für die UDP Checksum wird ein UDPPseudo-Header verwendet: 32 Bit – IP Source Address 32 Bit – IP Destination Address 08 Bit – Leerfeld 08 Bit – Protocol ID 16 Bit – Länge des UDP-Segments

Tabelle 7.9:

UDP – Übersicht zu den Parametern des Protokoll-Headers

7.3 Vorgehensweise Zunächst einmal muss man sich klar machen: Was kann schief gehen? Welche Fehler können in einem Weitverkehrsnetz, das mit Routern arbeitet, auftreten? Welche Störungen kann es bei Inter Process Communication (IPC) oder beim File Transfer geben? Und so weiter, und so weiter.

>>> NEW TECH

241

Kapitel 7 • TCP/IP-Grundlagen

Grundsätzlich kann man folgende Fehlerquellen abstrakt in Klassen fassen und die daran beteiligten Protokolle eingrenzen:

A

OSI Layer

Fehlerklasse, Protokolle, betroffene OSI Layer

2,3,5,7

Adress- und Namensauflösung (Resolution) bzw. Abfragen von Namen, Adressen und weiteren Informationen (LookUps): ARP-RARP (2,3), BOOTP (2,3), ICMP (3), DHCP (2,3,5,7), WINS (3,5), DNS (3,7)

B

3

Fehler im Routing bzw. in der Netzwerk-Vermittlung DHCP (2-7), IP (3), ICMP (3)

C

4

Fehler in der Datenfluss-Steuerung (Data Flow Control) DHCP (2-7), TCP (4), ICMP (3,4)

Tabelle 7.10: Die klassischen Fehlerquellen im TCP/IP-Umfeld

Hieraus folgen bestimmte Vorgehensweisen, um diese Standardquellen von Fehlern strukturiert »abzuklappern«; diese Vorgehensweisen werden in den nächsten Abschnitten erörtert. Unter »Vorgehensweise« ist in diesem Sinne zu verstehen, dass nach und nach durch Eingrenzung die Wirkungsweise des Fehlers verstanden wird, dass das eigentliche Fehlergeschehen erkannt und dann gezielt nach den Ursachen gesucht wird. Hier werden nun die häufigsten Fehler beschrieben, damit Sie in der Praxis nach und nach prüfen können, ob einer dieser Fehler im jeweiligen Fall vorliegt.

7.4 Adress- und Namensauflösung Um Fehler in der Adress- und Namensauflösung zu finden, müssen die zuständigen Protokolle überwacht werden.

7.4.1

Betriebsphase

Hierbei ist zu unterscheiden, in welcher Phase des Netzbetriebes ein Rechner unter Störungen zu leiden hat: In der Startphase (Boot-Phase) oder in der späteren Betriebsphase: Betriebsphase

Infrage kommende Protokolle

Startphase (Boot-Phase)

ARP, RARP, BOOTP, ICMP, DHCP, WINS, DNS

Spätere Arbeitsphase

ARP, WINS, DNS

Tabelle 7.11: Fehler in der Adress- und Namensauflösung je nach Betriebsphase

242

>>> NEW TECH

Adress- und Namensauflösung

Während der Startphase ist wesentlich auf die Protokolle BOOTP, DHCP, WINS und ARP zu achten, weil sie benutzt werden, um den Rechner zu konfigurieren: ■

■

■

■

Mit BOOTP oder DHCP fragt ein Rechner nach seiner IP-Adresse und/oder nach weiteren Einstellungen und Werten, etwa der IP Subnet Mask oder der IP-Adresse des DNS-Servers. Wenn bei dieser Initialisierung der Rechner ein Fehler unterläuft, können Fehler im späteren Betrieb schon fast nicht mehr ausbleiben. DHCP (Dynamic Host Configuration Protocol) ist ein Spezialfall des älteren BOOTP (Bootstrap Protocol), das ursprünglich für Diskless Workstations gedacht war. Das neuere DHCP ist umfassender; insbesondere wurde es auf die Bedürfnisse von Microsoft bzw. dessen Windows-Rechner abgestimmt. Die meisten Analyzer zeigen DHCP immer noch als BOOTP an. Mit ARP fragt eine IP-Station die MAC-Adresse (Ethernet, Token-Ring) einer anderen IP-Station ab. Während der Boot-Phase aber wird ARP von DHCP-Clients verwendet, um ihre IP-Adresse auf Einmaligkeit hin zu verifizieren. Mit RARP (Reverse ARP) fragt eine IP-Station, die über keine eigene Vorkonfiguration verfügt, ihre eigene IP-Adresse ab. RARP war vor BOOTP bzw. DHCP der gängige Mechanismus, um nach der eigenen IP-Adresse zu fragen. Heute ist RARP nur noch selten in Gebrauch. Mit ICMP können IP-Rechner nach Routern suchen oder die IP Subnet Mask abfragen. Dieser Mechanismus ist sehr selten geworden, findet aber eben doch dann und wann noch Anwendung. Allerdings sind die Rückgaben von Routern meistens fehlerfrei, denn wenn ein Router falsch konfiguriert wäre, würde das sofort und massiv auffallen – und nicht erst vereinzelt bei wenigen Stationen.

Fehler bei RARP, BOOTP oder DHCP haben meistens dann Wirkung, wenn die Vorgaben zum Routing oder zu WINS nicht stimmen. Die folgenden Szenarien sind typisch:

7.4.2

Die MAC-Addresse ist falsch zugewiesen (LAA)

Das Erscheinungsbild eines solchen Szenarios ist regelmäßig, dass IP-Rechner abstürzen, ihre Host-Sessions verlieren oder Applikationshänger aufweisen. Typisch ist ein solches Szenario eher für Token-Ring, da hier regelmäßig noch mit logischen Adapteradressen gearbeitet wird, – also nicht mit den werksseitig eingebrannten, weltweit einmaligen Hardware-MAC-Adressen (UAA, Universally Administered Address), sondern mit eigens zugewiesenen Software-MACAdressen (LAA, Local Administered Address). Bei Ethernet wurden logische Adressen ausgesprägt in DECnet-Umgebungen verwendet; außerhalb dessen ist der Gebrauch von LAA eher selten.

>>> NEW TECH

243

Kapitel 7 • TCP/IP-Grundlagen

Und doch: Es gibt LAN-Admins, die sich den LAA-Mechanismus zu Hilfe nehmen, um Zeit und Mühe für Dokumentation und Fehlersuche zu ersparen, indem sie wie folgt vorgehen: Sie setzen in die ersten drei Bytes (die sonst den Herstellercode enthalten) eine Abteilungskennung ein und hinterlegen diese wiederum in den Herstellertabellen des Analyzers. So zeigt der Analyzer online gleich an, aus welcher Abteilung eine MAC-Adresse kommt. Im Weiteren geben sie in den letzten drei Bytes die Telefonnummer des Schreibtisches ein, auf dem der Rechner steht. So kann mittels des hausinternen Telefonbuchs schnell und zuverlässig ermittelt werden, wer an bestimmten Datenübertragungen beteiligt ist. Im Falle einer solchen Verwendung logischer MAC-Adressen kann es geschehen, dass zwei (oder mehr) PCs dieselbe MAC-Adresse zugewiesen bekommen. Die Gründe für eine doppelte MAC-Adresse können also sein: ■

■

Es wurde in der Windows-Systemsteuerung (oder sonstwo in der TreiberKonfiguration) auf mehreren Rechnern dieselbe logische MAC-Adresse eingetragen. Für Token-Ring kommt zusätzlich die Möglichkeit in Betracht, dass über den RPS (Ring Parameter Server) einem Adapter eine MAC-Adresse zugewiesen wird, die bereits ein anderer Adapter manuell zugewiesen bekam. Dieses Szenario ist allerdings unwahrscheinlich, weil kaum noch mit RPS gearbeitet wird.

7.4.3

Die IP-Addresse ist falsch zugewiesen

Das Erscheinungsbild eines solchen Szenarios ist regelmäßig, dass IP-Rechner abstürzen, ihre Host-Sessions verlieren oder Applikationshänger aufweisen. Typisch ist – um ein Beispiel zu geben –, dass um 09:10 ein Anwender anruft und sagt, ihm sei die Netzwerkapplikation stehen geblieben. Nach einigem Hin und Her wird dem Anwender der Warmstart empfohlen. Um 09:15 ruft ein zweiter Anwender an und klagt über das gleiche Phänomen. Auch hier wird nach kurzer Debatte der Warmstart empfohlen. Um 09.20 ruft der erste Anwender wieder an mit derselben Klage. In solchen Fällen bedarf es noch nicht einmal mehr eines LAN-Analysators, um den Fehler zu erkennen: Immer, wenn der jeweils zweite und zeitlich letzte der beiden IP-Teilnehmer ans Netz geht, verliert der erste bzw. vorherige IP-Teilnehmer seine IP-Sessions – weil der Server bzw. Host aus seiner Sicht zu derselben IP-Adresse eine andere MAC-Adresse dargeboten bekommt und (für gewöhnlich) immer die letzte akzeptiert – was das »Aus« für den Anwender mit der (aus der Sicht des Hosts) »älteren« MAC-Adresse bedeutet. Einige Server bzw. Hosts sind in der Lage, dieses Ereignis zu erkennen und an der Console anzuzeigen.

244

>>> NEW TECH

Adress- und Namensauflösung

Die Gründe für eine doppelte IP-Adresse können sein: ■

■

■

Sollte ein DHCP-Server auf die DHCP-Nachfrage eines Arbeitsrechners eine falsche IP-Adresse zurück geben, wäre dies ein schwerer Fehler, der vermutlich erzwingen würde den DHCP-Server vollständig neu zu installieren. Ein solcher Fehler wurde vom Verfasser noch nicht beobachtet. Eine doppelt vergebene IP-Adresse führt dazu, dass die Kommunikationsbeziehungen Dritter mit dieser IP-Adresse nicht mehr eindeutig sind, da sich physikalisch zwei verschiedene Stationen darunter melden (könnten). Der Fehler einer doppelten IP-Adresse könnte dann auftreten, wenn alle oder einige der Rechner noch manuell konfiguriert werden/wurden (also noch nicht alle über DHCP eingestellt werden). In einer solchen gemischten Umgebung sind selbst DHCP-Clients nicht vor Fehlern gefeit: Zwar testet ein DHCP-Client, der vom DHCP-Server seine neue IP-Adresse zugewiesen bekam, diese mittels ARP-Requests auf Eindeutigkeit, indem er ARP-Broadcasts losschickt, die nach der zur eigenen IP-Adresse gehörenden MAC-Adresse fragen: Wenn ein zweiter Rechner diese IP-Adresse ebenfalls aufwiese, würde er antworten. So gesehen bietet das DHCP-Verfahren ein hohes Maß an Sicherheit, zumal auch der DHCP-Server diese Eindeutigkeit sicherstellt. Wenn aber eine zweite Station (a) dieselbe IP-Adresse verwendet durch manuelle Einstellung und (b) erst nach der ersten Station eingeschaltet wird, oder (c) in einem anderen IP-Subnet siedelt, das vom ARP-Adress-Test nicht erreicht wird, hilft der Sicherungsmechanismus von DHCP entweder gar nicht oder nur begrenzt. Bei einem solchen Szenario spielt der pure Zufall eine Rolle, wer an welchem Rechner arbeitet, wann wer morgens zur Arbeit kommt und wann wer den Rechner einschaltet. Deswegen muss bei Verdacht auf doppelte IP-Adresse genau nachgefragt werden, wann der Fehler auftritt: Früh am Morgen? Oder erst im Laufe des Tages? An jedem Tag? Das DHCP-Server-Modul bei WinNT4 lässt leider zu, dass IP-Adressen vergeben werden können, die der lokalen IP Subnet Broadcast Address entsprechen. Beispiel: In einem Subnetz mit den Adressen 192.99.32.x sollten zwei IP-Adressen grundsätzlich nicht vergeben werden: 192.99.32.0 und 192.99.32.255 – beide Adressen können als Broadcast-Adressen (miss)verstanden werden, wobei die Broadcast-Adresse »0« weitgehend unüblich, die Broadcast-Adresse »255« je Adress-Byte jedoch Standard ist. Der jeweils höchste Zahlenwert des letzten IP-Adress-Bytes stellt die Broadcast-Adresse dar; sie muss im DHCP-Server-Modul des Windows-NTServers manuell ausgeschlossen werden. Wenn ein IP-Rechner mit der IP-Broadcast-Adresse arbeitet, wird dies zwei schwerwiegende Fehler zur Folge haben:

>>> NEW TECH

245

Kapitel 7 • TCP/IP-Grundlagen

■

Erstens wird dieser Rechner jeden Subnet-Broadcast so behandeln, als sei er an ihn adressiert; dies kann bis zum Absturz des Rechners führen, falls eine zu große Zahl an Interrupt-Auslösungen die Folge sein sollte. Zweitens könnte es sein, dass mit diesem Rechner nur noch eine gestörte oder gar keine Kommunikation möglich ist, wenn die IP-Partner die missbrauchte Broadcast-Adresse nicht als Einzeladresse akzeptieren. Umgekehrt würde eine reibungslose Kommunikation unter diesen Bedingungen bewirken, dass alle IP-Pakete, die als Broadcast an diese Station gesendet würden, von allen anderen als Broadcasts verstanden und mitgelesen würden – mit letztlich unvorhersagbaren Folgen. Der Verfasser konnte bei einem Kunden einmal das kuriose Szenario erleben, dass einem IP-Router als Adresse die IP Subnet Broadcast Address zugewiesen worden war (manuell): Das Ergebnis war das perfekte Chaos.

WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\DhcpIPAddress HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\DhcpServer HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\Options\ Option# HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\EnableDhcp HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\IPAddress

7.4.4

Die IP Subnet Mask stimmt nicht

Das typische Erscheinungsbild dieses Fehlers ist, dass 1. IP-Verbindungen nicht zustande kommen, wenn die IP Subnet Mask zu eng gefasst ist, oder 2. IP Subnet Broadcasts über weitere, eigentlich davon nicht betroffene IP Subnets gestreut werden, wenn die IP Subnet Mask zu weit gefasst ist. Im ersten Fall merken die Anwender sofort nach dem Starten des Rechners, dass etwas nicht stimmt, weil sie eben ihrer Arbeit nicht nachgehen können. Dieses gilt aber nur, wenn bestimmte Server bzw. Dienste nicht mit einer eindeutigen IP-Adresse angerufen werden, sondern (zunächst) per IP-Broadcast. Dies geschieht beispielsweise auf der Suche nach WINS-Servern: Falls keine Adresse eines WINS-Servers bekannt ist, kann per IP-Broadcast nach ihnen gesucht werden. (Das Beispiel ließe sich auch mit DNS durchspielen.) Es sei auf den Abschnitt zu »WINS« verwiesen. Nun kann es sein, dass der Anwender bzw. sein Administrator immer annahmen, die Verwendung der WINS-Server sei bislang darauf zurückzuführen gewesen, dass die IP-Adresse des WINS-Servers der IP-Station bekannt gewesen

246

>>> NEW TECH

Adress- und Namensauflösung

sei (sei es durch DHCP, sei es durch manuelle Einstellung). Möglicherweise aber war diese Annahme schon immer falsch und der WINS-Server wurde schon immer nur durch Broadcast gefunden. Wenn nur die IP Subnet Mask verfälscht wird, funktioniert dieser Weg »hinten herum« nicht mehr, der WINS-Server wird nicht gefunden und alle Welt sucht nach einem WINS-Fehler. Aber dieses ist nur ein Beispiel von vielen, die denkbar wären. Im zweiten Fall merken die Anwender zunächst nichts, weil alle Verbindungen zustande kommen. Nach und nach aber merkt der Netzwerk-Admin, dass die Leitungen mit immer mehr Broadcasts verstopft werden. Insbesondere unter der Bedingung eines Filialnetzes, bei dem IP-Broadcasts über die WAN-Leitungen laufen, fällt das am Ende auch finanziell ins Gewicht, wenn keine Standleitungen, sondern Wählleitungen verwendet werden. Die Gründe für diesen Fehler könnten sein: Manuell eingestellte IP-Clients wurden falsch konfiguriert. Im diesem Falle wurde die IP Subnet Mask an den Endgeräten unmittelbar (in der Windows-Systemsteuerung) falsch eingegeben. ■ IP-Clients werden per DHCP falsch konfiguriert. Im diesem Falle wurde die IP Subnet Mask zentral am DHCP-Server falsch konfiguriert. ■ IP-Clients werden per BOOTP falsch konfiguriert. Im diesem Falle wurde die IP Subnet Mask zentral am BOOTP-Server falsch konfiguriert. ■ Theoretisch könnte eine falsche IP Subnet Mask per ICMP von einem Router abgefragt bzw. bezogen worden sein. Ein solches Szenario ist unwahrscheinlich, da sich ein solcher Fehler nur denken lässt, wenn der Router falsch eingestellt wäre – und das wäre sofort bemerkt worden ab Inbetriebnahme des Routers. Davon aber mal abgesehen ist es so, dass der ICMP-Mechanismus zur Abfrage von IP Subnet Masks praktisch kaum noch genutzt wird. Es besteht die Möglichkeit, WinNT-Maschinen so arbeiten zu lassen, dass sie alle IP-Subnetze als lokal gegeben ansehen, was den Weg über den Router ausschaltet. Wenn also auf in einem »flachen« LAN alle IP-Subnetze (bzw. alle IPTeilnehmer aller IP-Subnetze) physikalisch über den MAC Layer erreichbar sind, könnte die DHCP-Opotion 27 verwendet werden. ■

WinNT Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\Options\ 27 (=All subnets are local) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\DhcpSubnetMask HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\DhcpSubnetMaskOpt >>> NEW TECH

247

Kapitel 7 • TCP/IP-Grundlagen

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\SubnetMask HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\Options\ Option#

7.4.5

Der NetBIOS Name stimmt nicht

Jeder Versuch einer Auflösung des NetBIOS-Namens einer Gegenstelle in deren IP-Adresse ist zum Scheitern verurteilt, wenn schon der NetBIOS-Name (=Windows Maschinen-Name) nicht stimmt. Hier liegt in der Regeln ein Benutzerfehler vor; der Name wurde falsch angegeben. WinNT Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ ActiveComputerName HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\Options\ 1 (1=DhcpSubnetMaskOpt)

7.4.6

Der DNS Name stimmt nicht

Ähnlich liegt der Fall, wenn der Anwender einen falschen DNS-Namen (auch bekannt als »WWW-Name«) verwendet. Auch dann kann die Auflösung in die IP-Adresse der Gegenstelle nicht durchgeführt werden. Hier liegt in der Regeln ein Benutzerfehler vor; der Name wurde falsch angegeben. Denkbar ist aber auch, dass der DNS-Name des Windows-Rechners nicht richtig konfiguriert wurde. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Hostname

7.4.7

Die IP-Adresse des DNS-Servers stimmt nicht

Sind in der Windows-Systemsteuerung bzw. Registry falsche IP-Adressen für den/die DNS-Server hinterlegt, können nur noch DNS-Broadcasts die DNSServer erreichen; dies ist u.U. nicht der Fall. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\NameServer HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DHCP\Parameters\Options\ 6 (= DNS Server)

248

>>> NEW TECH

Adress- und Namensauflösung

7.4.8

Umgekehrte Namensabfragen bleiben erfolglos

Anders liegt der Fall bei WINS und DNS bei umgekehrten Abfragen (reverse resolution), bei denen unter Kenntnis der IP-Adresse nach dem Namen gesucht, dieser aber nicht gefunden wird. Dann wurde entweder die IP-Adresse falsch eingegeben (Benutzerfehler), oder der Name ist in den DNS-Tabellen nicht geführt (Sache des DNS-Admins, ggf. Sache des Tabellenaustauschs zwischen DNS-Servern).

7.4.9

Fehler im Address Resolution Protocol (R/ARP)

Fehler in R/ARP-Treibern sind nicht selten. Zu den häufigsten Fehlern, die der Autor beobachten konnte, gehören: ■

■

■

■

■

Es ist zwar die Auflösung mit ARP erwünscht, aber es wird ein RARPRequest geschickt oder eine Mixtur aus ARP und RARP. Der Autor konnte die Ursache für diesen Fehler bislang leider nicht ermitteln. Er tritt nach seiner Erfahrung eher unregelmäßig und unvorhersehbar auf. Wenn der Fehler auftritt, kommt auf den Broadcast keine Antwort; es findet also keine Adressauflösung statt, und der vorgesehene Verbindungsaufbau von A nach B scheitert. ARP arbeitet über Token-Ring nicht so, wie es nötig wäre; dies zielt auf das Token-Ring Source-Routing ab. Siehe Registry-Einträge am Ende des Abschnitts. ARP arbeitet über Ethernet mit dem falschen Frame-Type: Entweder über DIX bzw. Ethernet-II, oder über LLC-SNAP. Siehe Registry-Einträge am Ende des Abschnitts. ARP-Broadcasts gehen wie IP-Broadcasts auch über alle IP-Subnetze, weil die DHCP-Option 27 dies vorgibt. Dies dürfte zwar theoretisch nicht unbedingt zu Fehlern führen; aber Fehler, die bei vorheriger Verwendung von Routern noch unsichtbar waren, weil es zwischen verschiedenen IP-Subnetzen keine MAC-Broadcast-Verbindungen gab, könnten nun Wirkung zeigen. Dies wäre etwa gegeben, wenn zwei Rechner immer schon dieselbe IP-Adresse hatten, dies aber bislang nicht aufgefallen war. Dies ist zwar ein sehr seltener Fall, konnte aber schon beobachtet werden. Statt der Einser-Broadcast-Adresse, bei der die Broadcast-Adress-Bits sämtlich auf »1« gesetzt werden, wird die Nuller-Broadcast-Adresse verwendet, bei der die Broadcast-Adress-Bits sämtlich auf »0« gesetzt werden. In aller Regel verstehen sich ARP- und IP-Treiber, die sich durch unterschiedliche Verwendung der Broadcast-Bits auszeichnen, in keiner Weise. Die Adressauflösung scheitert, der Verbindungsaufbau kommt nicht zustande. Die Verwendung von Nuller-Broadcast-Adressen ist in TCP/IP-Treibern bei OS/2 häufiger der Fall gewesen; bei Microsoft-Treibern wird das Phänomen gelegentlich beobachtet.

>>> NEW TECH

249

Kapitel 7 • TCP/IP-Grundlagen

Da die Windows-Registry das Umsetzen von »1« auf »0« in den BroadcastBits zulässt, muss dringend geprüft werden, ob eine solche Einstellung in der Registry stattgefunden hat. WinNT Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\Options\ Option# HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\Options\ 27 (=All subnets are local) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\UseZeroBroadcast HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ ArpCacheLife HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ ArpAlwaysSourceRoute HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ ArpTRSingleRoute HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ ArpUseEtherSNAP

7.5 Routing-Fehler/Default Gateway Routing-Fehler können in verschiedener Art auftreten: ■ ■ ■

Pakete laufen über andere Wege als vorgesehen. Pakete werden vor Auslieferung an den Adressaten verworfen. Pakete sind durch falsche Routing-Vorgaben doppelt auf der Leitung.

Für die nachfolgend aufgeführten Szenarien gilt: Zum Default Gateway und der IP Subnet Mask unter MS-Windows können die folgenden Registry-Einträge (hilfsweise) zu Rate gezogen werden. MS Windows NT Registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ ..\Dhcp\Parameters\Options\Option# ..\Dhcp\Parameters\Options\1 (=Subnet Mask Option) ..\Dhcp\Parameters\Options\27 (=All subnets are local) ..\Tcpip\Parameters\EnableDeadGWDetect ..\AdapterName#\Parameters\Tcpip\DefaultGateway ..\AdapterName#\Parameters\Tcpip\DhcpDefaultGateway ..\AdapterName#\Parameters\Tcpip\DhcpSubnetMask ..\AdapterName#\Parameters\Tcpip\DhcpSubnetMaskOpt ..\AdapterName#\Parameters\Tcpip\DontAddDefaultGateway ..\AdapterName#\Parameters\Tcpip\SubnetMask Tabelle 7.12: WinNT Registry Keys – Default Gateway – IP Subnet Mask

250

>>> NEW TECH

Routing-Fehler/Default Gateway

7.5.1

Pakete laufen über andere Wege als vorgesehen

Dieses Geschehen kann verschiedene Ursachen haben: ■

■

■

■

Router-Fehler Die Routing-Tabellen bzw. die Routing-Algorithmen der Router arbeiten nicht so wie erwünscht. Dies kann durch Software-Fehler, aber auch durch Konfigurationsfehler ausgelöst werden, insbesondere dann, wenn mit sog. statischen Routen (fest eingestellen Wegevorgaben) gearbeitet wird und diese nicht stimmen. Routenausfall und Umleitung Vorgesehene Routen sind ausgefallen, weil Router oder Leitungen ausgefallen sind, die im vorgesehenen Weg liegen; dann wird im besten Fall der Verkehr umgeleitet (wenn er schon nicht völlig zum Erliegen kommt). Falsche Einstellung im Client-PC Der Eintrag Default Gateway in den Client-PCs stimmt nicht. Falsche Einstellung im DHCP-Server Der Eintrag Default Gateway ist im DHCP-Server falsch eingegeben.

Hier hilft einerseits eine Überprüfung der Einstellungen bei Routern und ClientPCs, andererseits helfen Messungen mit dem LAN-Analysator: Es ist mit mäßigem Aufwand zu erkennen, über welchen Weg die Pakete tatsächlich laufen, und sodann ist klar, ob dies der gewünschten Vorgabe entspricht (oder nicht). Seitens der Client-PCs ist der Fall oft gut lösbar, wenn bereits über DHCP gearbeitet wird; dann reicht oft eine Korrektur am DHCP-Server. Eine schnelle Diagnose ist manchmal auch möglich über einen TraceRouteBefehl: Insofern die Reihenfolge der überquerten Router erkannt werden kann, wird ebenfalls der Verkehrsweg klar (allerdings nicht die Ursache für einen Fehler). Siehe hierzu auch: Tabelle 7.12: WinNT Registry Keys – Default Gateway – IP Subnet Mask.

7.5.2

Pakete werden von Routern verworfen

Die Gründe für ein Verwerfen von IP-Paketen seitens der Router können vielfältig sein. Für gewöhnlich folgt auf das Verwerfen seitens des Routers eine ICMP-Rückmeldung an den Absender, dessen Paket verworfen wurde: ■

TTL-Wert zu gering Die Pakete müssen über (zu) viele Router laufen, ohne vom Absender mit einem ausreichenden TTL-Wert (Hop Credit) ausgestattet worden zu sein. ICMP: »Time Exceeded/TTL=0«

>>> NEW TECH

251

Kapitel 7 • TCP/IP-Grundlagen

IP-Fragmentation nicht erlaubt IP-Pakete müssten seitens eines Routers fragmentiert werden, um vermittelt werden zu können; der Absender hat aber das Fragmentieren verboten, und eine andere Route steht entweder nicht zur Verfügung oder wird vom Absender nicht akzeptiert. ICMP: »Fragmentation Needed« ■ IP-Fragmentation fehlerhaft Zerlegte (fragmentierte) IP-Pakete können nicht mehr vollständig zusammengesetzt werden, weil beim letzten Router, der das Re-Assemblieren besorgen soll, nicht mehr alle Fragmente eintreffen. ICMP: »Time Exceeded/ReAssembly Timer Expired« ■ Router ist überlastet Ein Router leidet unter Überlast, die durch einen bestimmten Absender verursacht wird; nach einiger Zeit und einigen Vorwarnungen entschließt sich der Router, keine IP-Pakete dieses Absenders mehr zu vermitteln. ICMP: »Source Quench/Datagram Could Not Be Routed« ■ Die Route bzw. das IP-Subnetz ist unbekannt Das IP-Zielnetz, das sich aus der IP Destination Address ergibt (ggf. unter Zuhilfenahme der IP Subnet Mask), kann vom Router in seinen Tabellen nicht gefunden werden oder ist nicht verfügbar. ICMP: »Destination Unreachable/Network Unreachable« ■ Die vorgeschriebene Source-Route ist nicht gegeben Es sind zwar Wege zum IP-Zielnetz vorhanden; diese entsprechen aber nicht der Wegevorgabe des Absenders; darum wird das Paket verworfen. ICMP: »Destination Unreachable/Source Route Not Available« ■ Der Empfänger ist nicht bekannt bzw. nicht eingeschaltet Der laut IP Destination Address angegebene Empfänger ist dem Router nicht bekannt (ist in seinem ARP-Cache nicht enthalten), und auf ARPBroadcasts des Routers antwortet der Empfänger auch nicht. ICMP: »Destination Unreachable/Host Unreachable« Solche Ereignisse werden von Routern für gewöhnlich immer an den Absender via ICMP gemeldet (s.u.); jedoch sind insbesondere Microsoft-Rechner nicht sonderlich daran interessiert, diese Meldungen an den Anwender weiterzugeben oder gar die richtigen Schlüsse daraus zu ziehen und die richtigen Maßnahmen einzuleiten. ■

Die Rückmeldungen der Router lauten (Tabelle 7.13): Type

Code

Bedeutung

0

Netz ist nicht erreichbar

Router

1

Rechner ist nicht erreichbar

Router

03

Absender

Destination Unreachable/Unzustellbar

Tabelle 7.13: ICMP-Meldungen von Routern wegen Paketverwerfung

252

>>> NEW TECH

Routing-Fehler/Default Gateway

Type

Code

Bedeutung

Absender

4

Fragmentierung nötig, aber nicht gestattet

Router

Source Route nicht erreichbar

Router

5 04

Source Quench/Überlastung durch Sender 0

11

Datagramm konnte nicht bearbeitet werden

Host, Router

Time Exceeded/Zeitüberschreitung 0

TTL auf 0 gefallen/IP-Paket wurde verworfen

Router

1

Reassembly-Timer abgelaufen (Fragmentation)

Router

Tabelle 7.13: ICMP-Meldungen von Routern wegen Paketverwerfung (Forts.)

Siehe hierzu auch: Tabelle 7.12: WinNT Registry Keys – Default Gateway – IP Subnet Mask.

7.5.3

Pakete laufen doppelt: Local Loop

Es gibt hauptsächlich zwei Szenarien, unter denen IP-Pakete doppelt auf derselben Leitung sind, was allgemein als Local Routing oder Local Loop bezeichnet wird: ■

■

Zwei Router, aber nur ein Default Gateway Es gibt in einem LAN-Segment mindestens zwei IP-Router; der Weg zum Empfänger (z.B. Server) führt über Router B, aber Router A ist als »default gateway« in den Endgeräten konfiguriert. Somit schicken die Endgeräte die IP-Pakete an Router A; dieser leitet sie weiter an Router B, schickt aber noch eine ICMP-Meldung zurück an den Absender, damit dieser sodann seine IP-Pakete direkt an Router B senden möge (eine Folge, die bei Mircosoft-Rechnern nicht mit Gewissheit eintritt): ICMP: »Redirection« Ein Router, aber zwei IP-Subnets im LAN Sowohl IP-Absender wie auch IP-Empfänger sind im selben physikalischen LAN-Segment angeschlossen. Sie sind aber – subjektiv für den IP-Absender – in unterschiedlichen IP-Subnetzen angesiedelt, wobei diese Auffassung von der IP-Subnet-Mask abhängt. Aus der Sicht des Routers ist dies ein sog. Multi-Homing (mehrere IP-Subnetze auf demselben physikalischen LAN) und stellt eine Vorstufe zu heutigen VLANs dar. Seitens des Endgerätes könnte das lokale Routing vermieden werden, wenn die Subnet-Mask entsprechend verändert würde; dies wäre aber nur dann möglich, wenn der Router von den Endgeräten ansonsten nicht gebraucht würde (was kaum anzunehmen ist). Gemeint ist ein Umsetzen der Subnet Mask etwa von 255.255.255.0 auf 255.255.0.0. Ansonsten entfallen diese Probleme heute unter zusätzlichem Einsatz der sog. Layer-3-Switches (L3X), also routingfähigen LAN-Switches der neuesten Generation.

>>> NEW TECH

253

Kapitel 7 • TCP/IP-Grundlagen

Findet seitens des Routers ein solches Local Routing statt, erfolgt auch hier eine Rückmeldung an den Absender der Art, dass er sich doch bitte direkt an den Empfänger wenden möge, anstatt über den Router zu gehen: ICMP: »Redirection« Die entsprechenden ICMP-Meldungen sind (Tabelle 7.14): Type

Code

05

Bedeutung

Absender

Redirect/Umleitung der Datagramme ... 0

... zu einem bestimmten IP-Netz

Router

1

... zu einem bestimmten Host

Router

2

... für einen bestimmten Service- und Netz-Typ

Router

3

... für einen bestimmten Service-Typ und Host

Router

Tabelle 7.14: ICMP-Meldungen von Routern mit Umleitungsempfehlung

Zum Default Gateway und der IP Subnet Mask unter MS-Windows können die in Tabelle 7.12 aufgeführten Registry-Einträge zu Rate gezogen werden.

7.5.4

Router und ICMP

Wie die vorstehenden Beispiele gezeigt haben, ist ICMP von erheblicher Bedeutung für das Verständnis vieler Fehler oder Ereignisse, bei denen IP-Router beteiligt sind. Darum soll ICMP ausführlich erklärt werden.

7.6 Im Fokus des Analyzers: ICMP LAN-Analyse fällt dann am leichtesten, wenn – sozusagen – das Netz sich selbst diagnostiziert. Dies ist insofern bei TCP/IP-Komponenten der Fall, wie sie Fehler in der Zustellung von IP-Paketen mittels ICMP melden. Ein Filter auf ICMP sollte zu den ersten Standardtests gehören: Protokollkennung »1« im Feld Protocol innerhalb des IP-Headers bei Offset=9; der MACHeader ist zum Offset hinzuzuzählen (und beträgt 14 Byte, sofern ohne TokenRing Source-Routing gearbeitet wird). Filter auf (Protokoll-Feld/Parameter) ...

Offset

Wert (hex)

Ethernet II + IP + ICMP

23

01

LLC-SNAP + IP + ICMP

28

01

Tabelle 7.15: Filter auf ICMP (bei Token-Ring: ohne Source-Routing)

254

>>> NEW TECH

Im Fokus des Analyzers: ICMP

Der ICMP-Filter sollte kombiniert werden mit einem Filter auf IP, weil der Hex-Wert 0x01 am jeweiligen Offset sicher auch in anderen Paketen zufällig vorkommt. Besser ist ein Filter, dem vom Analyzer angeboten wird (Abbildung 7.6):

Abbildung 7.6: Filter auf Pakete mit ICMP

Die ICMP-Meldungen sind wie folgt zu verstehen:

7.6.1

ICMP: »Destination Unreachable«

Aus historischen Gründen werden zu den jeweiligen ICMP-Meldungen die Unix-Config-Dateien angegeben, die bei der Entwicklung von TCP/IP auf Unix Ende der 70er und Anfang der 80er Jahr eine Rolle spielten, aber heute zum Teil nicht mehr in Gebrauch sind. »Network Unreachable« Ein Router meldet an den Absender eines IP-Paketes, dass er eines seiner IPPaket verwerfen musste, weil er keinen Weg zum angegebenen IP-Zielnetz finden konnte. Vermutlich war das Ziel-IP-Netz nicht in seinen Routing-Tabellen enthalten, oder der Weg war gestört. Am Ende der ICMP-Meldung ist der originale IP-Header des verworfenen Paketes samt der TCP/UDP-Port-Adressen enthalten; es besteht also kein Zweifel darüber, welches Paket verworfen wurde, da der Absender sein eigenes Paket (theoretisch) exakt wiedererkennen kann. Auf Unix-Rechnern, die als Router arbeiten, könnte bei statischen Routen ein Eintrag in der entsprechenden Config-Datei falsch sein oder fehlen: /etc/gateways

>>> NEW TECH

255

Kapitel 7 • TCP/IP-Grundlagen

WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Persistent Routes

»Host Unreachable« Der letzte Router in der Vermittlungskette, der den Zugriff auf das LAN des Empfängers hat, meldet, dass der Empfänger nicht erreichbar ist. Vermutlich ist der Rechner, an den das IP-Paket gerichtet ist, schlicht nicht am Netz (ausgeschaltet). Der Original-Header des verworfenen IP-Paketes samt der danach folgenden TCP/UDP-Port-Adressen ist in der ICMP-Rückmeldung enthalten. Auf Unix-Rechnern ältester Bauart (die es heute vermutlich gar nicht mehr gibt), wurden die Tabellen mit den IP- und MAC-Adressen lokaler Teilnehmer nicht per ARP geführt, sondern in einer Config-Datei: /etc/ethers

»Protocol Unavailable« Der IP-Treiber des Empfängers meldet, dass das höhere (Schicht-4-) Protokoll bei ihm nicht bekannt bzw. nicht geladen ist, an das die Daten oberhalb von IP gerichtet sind. Dies kommt selten vor und entspräche etwa dem Szenario, dass der Absender den UDP-Dienst des Empfängers anspricht, dort aber der UDP-Treiber nicht geladen ist. Der Original-Header des verworfenen IP-Paketes samt der danach folgenden TCP/UDP-Port-Adressen ist in der ICMP-Rückmeldung enthalten. Auf Unix-Maschinen gibt es für die oberhalb von IP beförderten Protokolle eine Config-Datei, die ggf. betroffen ist: /etc/protocols

Bei Windows-Rechner kann der Gebrauch bestimmter IP-Protokolle gezielt unterbunden werden. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ EnableSecurityFilters HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\RawIPAllowedProtocols

Siehe auch die in Abbildung 7.29 gezeigte ICMP-Meldung. »Port Unavaible« Das jeweilige Transportprotokoll (TCP oder UDP) meldet, dass mit dem angegebenen Destination Port (Socket) kein Prozess (Service) verbunden ist. Das

256

>>> NEW TECH

Im Fokus des Analyzers: ICMP

Paket kann also keiner Applikation bzw. keinem höheren Protokolldienst übergeben werden. Der Original-Header des verworfenen IP-Paketes samt der danach folgenden TCP/UDP-Port-Adressen ist in der ICMP-Rückmeldung enthalten. Auf Unix-Maschinen gibt es für die oberhalb von UDP und TCP beförderten Protokolle eine Config-Datei, die ggf. betroffen ist: /etc/services

Bei Windows-Rechner kann der Gebrauch bestimmter TCP/UDP-Ports gezielt unterbunden werden. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ EnableSecurityFilters HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\TcpAllowedPorts HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\UdpAllowedPorts

7.6.2

ICMP: »Redirection – Gateway Address«

Insofern die ICMP-Meldung »Network Unreachable« bereits einen RoutingFehler benennt, erkennt die innewohnende Logik einen weiteren Fehlerzustand, nämlich, dass der Absender (das kann auch ein vorgeschalteter Router sein) das Paket über einen (zwar möglichen, aber) ungünstigen (und darum falschen) Weg geschickt hat. In dieser Situation würde ein Router melden: »ICMP – Redirection« unter Nennung der IP-Adresse exakt des Routers, über den das Paket eigentlich hätte geschickt werden sollen. Diese Fehler geschehen im LAN insbesondere dann, wenn bei den Endgeräten die Angabe für das Default Gateway (auch: Standard-Router) nicht stimmt oder nicht verändert werden kann. Ansonsten kann diese Meldung auf einen fehlerhaften Routing-Algorithmus in einem der Router deuten.

HINWEIS MS-Windows-Rechner kommen der Umleitungsanweisung manchmal aus unerklärlichen Gründen nicht nach, obwohl ihnen seitens der Router klar gesagt wurde, wohin sie die Pakete zu richten haben. Insbesondere bei WinNT mit Service-Pack 4 wurde vom Autor manches Mal beobachtet, wie WinNT-Rechner die ICMP-Redirection-Meldungen gar nicht oder nicht ausreichend berücksichtigt haben – obwohl die Masse der WinNT-Rechner (SP4) sehr wohl damit umgehen konnte.

>>> NEW TECH

257

Kapitel 7 • TCP/IP-Grundlagen

Das Problem besteht im Kern darin, dass die Zahl der Einträge in der WindowsRegistry, die mit TCP/IP zu tun haben, so groß ist, dass oft die Zeit nicht bleibt, nach versteckten Fehlern zu suchen. Das Problem besteht aber fortgesetzt und zusätzlich darin, dass die Einträge in der Windows-Registry zu großen Teilen nur die Startwerte der jeweiligen Parameter enthalten; wenn verschiedene höhere Treiber und Applikationen auf die TCP/IP-Treiber einwirken, kann nicht mehr nachvollzogen werden, welche Komponente ggf. die verwendeten Treiberparameter verstellt. Eine leider typische Fehlermeldung von Windows-Rechnern nach Erhalt einer Meldung »ICMP: Redirection« ist das allseits bekannte: »Von Gerät Netzwerk kann nicht gelesen werden.« Das kann bestenfalls nur noch als schlechter Witz bezeichnet werden: Externe Dienstleister wie der Autor verdienen ihr Geld (auch) damit, dass sie ICMPMeldungen per Analyzer sichtbar machen, die MS-Windows locker von sich aus auf den Bildschirm bringen könnte! Es ist unfassbar. WinNT Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\Options\ Option# HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\DefaultGateway HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\DhcpDefaultGateway

Die ggf. betroffene Config-Datei bei Unix ist: /etc/gateways

Wenn das dynamische Routing nicht funktioniert und wenn das Default Gateway nicht verändert werden kann, könnte noch die manuelle Eingabe einer neuen Route helfen: /etc/route add

Bei MS-Windows kann das Programm ROUTE.EXE entsprechend eingesetzt werden. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ PersistentRoutes

7.6.3

ICMP: »Time Exceeded – TTL Expired«

Jedes IP-Paket hat von vornherein eine begrenzte Lebensdauer, ausgedrückt in einem sog. Hop Credit: Das Paket darf nur über eine maximale Zahl von Routern laufen (eine Router-Überquerung ist ein Hop, ein »Hüpfer«).

258

>>> NEW TECH

Im Fokus des Analyzers: ICMP

Hierfür wird jedem IP-Paket gewissermaßen ein Dukatenbeutel als Guthaben mitgegeben (der Hop Credit) und jeder Router erhebt Zoll, indem er wenigstens einen Dukaten vereinnahmt (Verminderung des TTL-Wertes um mindestens »1«). Ist der Geldbeutel leer, wird das IP-Paket verworfen. Der Hop Credit bzw. der IP-Parameter, der den aktuellen Wert enthält, heißt Time To Live (TTL). Durch diesen Mechanismus kann verhindert werden, dass IP-Pakete bei RoutingFehlern endlos im IP-Netz kreisen. Kommt eine solche ICMP-Meldung zurück, wurde entweder vom Absender ein zu geringer TTL-Wert mitgegeben, oder das Paket lief über einen anderen (teureren) Weg als sonst; im schlechtesten Falle irrte es im Internet herum. WinNT Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\Options\ 37 (= Default TTL Option) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\DefaultTTL

Die Veränderung des Vorgabewertes für TTL ist wenig hilfreich, da die verschiedenen höheren Treiber und Applikationen den TTL-Wert dynamisch verändern können.

7.6.4

ICMP: »Time Exceeded – ReAssembly Timeout«

Wurden IP-Pakete in sog. IP-Fragmente zerlegt, kann es passieren, dass sie an anderer Stelle nicht wieder vollends zusammengesetzt werden konnten. Dann wird gemeldet, dass die Wartezeit zum Eintreffen aller Fragmente überschritten war, ohne dass alle Einzelteile (fragments) eingetroffen waren. IP-Fragmentieren kann z.B. notwendig sein, wenn zwischen zwei Token-RingLANs als Transitstrecke ein Ethernet-Segment liegt. Token-Ring kann Pakete von bis zu 4.096 Byte übertragen (teilweise mehr), Ethernet nur bis 1.518 Byte. Falls die Endgeräte sich nicht freiwillig auf ein Maximum von 1.518 Byte beschränken, müssen die dazwischen liegenden Router die für Ethernet zu großen IP-Pakete fragmentieren. Treffen auf der gegenüberliegenden Seite beim dortigen Router nicht alle Fragmente ein, werden auch die bislang bereits eingetroffenen Fragmente verworfen. Sodann erfolgt die ICMP-Meldung an den Absender, dass dies eingetreten ist. Jeder IP-Absender kann in seinen Paketen ein »Don’t Fragment«-Bit setzen, das Routern das Fragmentieren verbietet. Hierdurch sind die Router gezwungen, ■ ■

das Paket über einen vielleicht längeren Weg zu schicken, der dafür aber die nötige Paketgröße unterstützt, oder aber das Paket zu verwerfen. (siehe: ICMP: »Fragmentation Needed«).

>>> NEW TECH

259

Kapitel 7 • TCP/IP-Grundlagen

Die Meldungen von Routern, dass sie wegen ausstehender Fragmente das Paket verwerfen mussten, kann unmittelbar nichts bewirken; allenfalls der NetzwerkAdministrator kann prüfen, ob und warum ggf. eine erhöhte Paketverlustrate vorliegt.

HINWEIS Zum Default Gateway und der IP Subnet Mask unter MS-Windows können die in Tabelle 7.12 aufgeführten Registry-Einträge zu Rate gezogen werden.

7.6.5

ICMP: »Fragmentation Needed«

Das beim Router eingetroffene IP-Paket müsste jetzt in kleinere Fragmente zerlegt werden; dies kann aber nicht durchgeführt werden, da der Absender genau dies über das IP-Fragmentation-Flag Don’t Fragment (DF) untersagt hat. Der Router verwirft das Paket und meldet das Ereignis zurück. Die Reaktion von Windows-Rechnern bzw. ihren Applikationen ist höchst ungewiss; nach allgemeiner Erfahrung des Autors merkt der Treiber bzw. die Applikation nicht, was die Meldung eigentlich bedeutet, und versucht es weiter mit Don’t Fragment – was zum völligen Versagen der IP-Kommunikation führen kann. Es könnte ein Fehler im Aushandeln der sog. TCP Maximum Segment Size (MSS) bzw. im Austesten der Maximum Transmission Unit (MTU) der Transitsegmente vorliegen; das aber wäre bezüglich der MSS von geradezu exotischer Seltenheit. WinNT Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\Options\ Option# (22,24,25,26) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\MTU HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ EnablePMTUBHDetect HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ EnablePMTUDiscovery

HINWEIS Zum Default Gateway und der IP Subnet Mask unter MS-Windows können die in Tabelle 7.12 aufgeführten Registry-Einträge zu Rate gezogen werden.

260

>>> NEW TECH

Im Fokus des Analyzers: ICMP

7.6.6

ICMP: »Source Quench«

Wird ein IP-Empfänger so überlastet, dass er eingehende Pakete verwerfen muss (in der Regel wegen Pufferüberlaufs), so meldet er doch wenigstens noch an den Absender zurück: »ICMP: Source Quench«. Dies besagt: Der Empfänger (Router, Host) fühlt sich von den IP-Paketen des Absenders (Source) erdrückt (Quench). Eher noch als ein Endgerät meldet dies ein Router; dies ist gleichzeitig eine Aufforderung an den Absender, mal »halblang« zu machen, also weniger bzw. langsamer zu senden, also mit längeren Pausen zwischen den IP-Paketen. Der Autor konnte einmal beobachten, wie ein Cisco-Router geradezu verzweifelt einem WinNT-Server in immer kürzeren Abständen »ICMP: Source Quench« meldete – und da dieser WinNT-Server das nicht begriff, hörte der Router schlicht auf, IP-Pakete dieses Servers zu bedienen: Mit der Folge, dass alle IP-Dialoge, die über diesen Router zu jenem Server liefen, aufhörten. Es sind keine Einträge in der WinNT-Registry bekannt, die hier helfen könnten.

7.6.7

ICMP: »Echo Request/Echo Reply«

Der allseits bekannte Befehl »ping« arbeitet mit den ICMP-Funktionen »Echo Request/Echoe Reply«. ICMP & Ping Irrigerweise nehmen viele Netzwerker an, dass die IP-Strecke zwischen Client und Server OK sein müsse, wenn man mit einem Ping die Gegenstelle erreichen kann. Mitnichten! Die meisten Ping-Programme senden per Voreinstellung nur kleine Pakete mit einer Größe von 64 Byte; das entspricht der Mindestpaketgröße bei Ethernet. Wenn der Fehler aber nur bei größeren Paketen auftritt, so ist der erfolgreiche »Ping« schlicht nichts wert. Das wahrscheinlichste Szenario für die Sinnlosigkeit eines 64-Byte-Pings sind Probleme mit dem IP-Fragmenting: Ein Router verwirft alle großen Pakete, weil er sie nicht fragmentieren darf. Siehe hierzu: Abschnitt 7.6.5 »ICMP: Fragmentation Needed«. Daher sind nur solche Ping-Programme sinnvoll, die mit wechselnden Paketgrößen die IP-Strecke austesten, also etwa mit 64, 128, 512, 1.024, 1.518, 2.048, 4.096 Byte (die letzten beiden Größen nur bei Token-Ring). Der Autor empfiehlt die von ihm verwendeten Programme WS_Ping und What’s Up Gold (Ipswitch, USA, http://www.ipswitch.com/).

>>> NEW TECH

261

Kapitel 7 • TCP/IP-Grundlagen

ICMP & TraceRoute Die genannten Ping-Programme von Ipswitch, aber auch andere, sind zudem in der Lage, durch Inkrementieren der TTL-Werte sowie durch DNS-Namensauflösungen den Weg der IP-Pakete durchs Internet (Extranet, Intranet) nachzuvollziehen. Hierdurch werden die Routing-Wege sichtbar gemacht und entsprechende Fehler leichter gefunden. Unter den ersten TraceRoute-Implementationen auf Unix-Rechnern ... /etc/traceroute

... waren solche, die diesen Mechanismus mit der Funktion IP Option: Record Route vollzogen: Hierbei wird im IP-Paket eine Markierung gesetzt, die jeden Router veranlasst, seine IP-Adresse im IP-Header einzutragen. Da jedoch nicht alle Router diesen Mechanismus unterstütz(t)en, verwendet man heute für die TraceRoute-Funktion den Mechanismus, ICMP-Pakete mit langsam ansteigenden TTL-Werten zu verwenden; dieses Verfahren sorgt dafür, dass immer der nächstfolgende Router in der Vermittlungsstrecke das ICMPPaket zu verwerfen hat (weil der TTL-Wert bei ihm auf Null fällt) – mit der Folge, dass der Router dann seinerseits die ICMP-Meldung zurückschickt »IMCP: Time Exceeded«. Diese Meldung ist an sich völlig uninteressant für den TraceRoute-Anwender; was allein interessant ist, ist die IP-Adresse des meldenden Router, die dann ihrerseits via DNS in einen DNS-Namen umgesetzt wird. Um diese reversive DNS-Namensauflösung möglichst gut zu unterstützen, bietet das WS_Ping von Ipswitch die Möglichkeit an, hierbei einen anderen DNSServer abzufragen, als in der Windows-Systemsteuerung hinterlegt ist. WinNT Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\Options\ Option# HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\NameServer

7.6.8

Grenzen von ICMP

ICMP kann nicht alle Fehler melden, weil nicht alle Fehler von den beteiligten Komponenten erkannt werden können; insbesondere Fehler im Bereich der TCP Data Flow Control werden nicht sichtbar. Was gut unterstützt wird, ist das Auffinden von Fehlern, die mit Routern zusammenhängen. Häufig kommt es vor, dass Router korrekte ICMP-Meldungen senden, die wirklich alles beinhalten, was wichtig ist – was dann aber schlicht nichts nutzt, weil Microsoft die Idee hatte, nichts dergleichen auf den Bildschirm zu bringen. Allenfalls melden Win95/98/NT-Stationen: »Von Gerät Netzwerk kann nicht gelesen werden«.

262

>>> NEW TECH

Im Fokus des Analyzers: IP

Na, prima – und noch falsch dazu! Auch wurde schon beobachtet, dass WinNT-Server (Version 4) weder »ICMP: Redirection«, noch »ICMP: Source Quench« richtig behandelten. Wenn es erst einmal so weit gekommen ist, bleibt in der Tat nichts anderes mehr übrig, als den LAN-Analysator herauszuholen, um auf der Leitung mitzulesen, was denn da los ist.

7.7 Im Fokus des Analyzers: IP Fehler in IP-Treibern gehören eher zu den Raritäten. Wenn im Zusammenhang mit IP Fehler auftreten, so wegen der bereits weiter oben genannten Fehler in den Konfigurationen von Routern, Clients und Servern. Gleichwohl kann man den IP-Headern mittels LAN-Analysator das eine oder andere Geheimnis entreißen bzw. sich kleine Eigenheiten zunutze machen.

Abbildung 7.7: IP Header im LANdecoder32 (IP over DIX/Ethernet II)

>>> NEW TECH

263

Kapitel 7 • TCP/IP-Grundlagen

Insgesamt aber ist die Zahl der Fehler, die mit IP verbunden sind (sein können), beträchlich groß. Obwohl die nachfolgenden Beschreibungen sicher nicht alle denkbaren IP-Fehler erfassen (können), sind doch die wichtigsten und gängigsten Fehler aufgeführt. Zur besseren Übersicht sei ein IP-Paket vorangestellt.

7.7.1

IP: Version/Header Length

Filter auf IPv4 lassen sich manuell etwas zuverlässiger setzen, wenn sie nicht allein auf den Wert EtherType=0x0800 gesetzt werden, sondern auch auf die nachfolgenden acht Bits, weil diese die IP Version (4 Bit) und die IP Header Length (4 Bit) enthalten, die bei IPv4 praktisch immer den Wert 0x45 haben, so lange keine IP Options verwendet werden.

Abbildung 7.8: Filter auf IP mittels der Hex-Folge 0x080045

Der Vorteil dieser Filtervariante ist ein doppelter: Einerseits sind solche HexFilter oft schneller als vorgefertigte Filter des Analyzers (siehe unten, Abbildung 7.1), andererseits können sämtliche IP-Varianten (mit Ausnahme von NetwareIP) damit erwischt werden: ■

264

IP über Ethernet II/DIX

>>> NEW TECH

Im Fokus des Analyzers: IP

IP über LLC-SNAP ■ IP-Header in ICMP-Meldungen (indirekt) Hierfür sorgt die Einstellung »Offset: Anywhere« statt der sonst zutreffenden Offset-Angabe »0x0C«, die auf das 13. Byte (=Offset von 12) im MAC-Header weist, wo sich der EtherType mit 0x0800 befindet. ■

Im Ergebnis sind beide Filter gleich.

Abbildung 7.9: Filter auf IP/Angebot des Analyzers

7.7.2

IP: Type of Service (ToS)

Die IP-Parameter zum Type of Service (ToS) wird allgemein nicht verwendet. Falls dies ein Teilnehmer dennoch tut, muss er damit rechnen, dass dies bei den Routern, die das IP-Paket durchläuft, keine Wirkung auslöst.

Abbildung 7.10: IP-Parameter Type of Service (ToS)

>>> NEW TECH

265

Kapitel 7 • TCP/IP-Grundlagen

Die ToS-Parameter waren ursprünglich dazu gedacht, bestimmten IP-Paketen bei den Routern eine Bevorzugung zu verschaffen: IP ToS Parameter

Bedeutung

Normal/High Reliability

Das IP-Paket soll über eine Leitung mit normaler oder hoher Zuverlässigkeit gesendet werden.

Normal/High Throughput

Das IP-Paket soll über eine Leitung mit normaler oder hoher Bitrate (Durchsatz) gesendet werden.

Normal/Low Delay

Das IP-Paket soll in der Warteschlange des Routers normal behandelt oder gleich nach vorne gestellt werden.

Routine Precedence (Y/N)

Das IP-Paket soll allgemein von der Routing Engine bevorzugt behandelt werden.

Tabelle 7.16: Bedeutung der IP-ToS-Parameter

Dies war für die US-Militärs von Belang; im privaten Internet hat sich die Verwendung von IP-ToS nicht durchgesetzt. Wenn bestimmte IP-Pakete bzw. IP-Sessions bevorzugt durchs Netz gebracht werden sollen, wird dies heute auf den verschiedenen Netzwerkschichten eher wie folgt erreicht: ■ ■ ■

Layer 2: VLAN Priority Tag Layer 3: RVSP = Resource Reservation Protocol Layer 4: RTP = Real Time Protocol

In aller Regel dürfte bei der IP-Analyse die ToS-Funktion ohne Belang sein. Der Vorgabewert bei MS-Windows-Rechnern ist ToS=0, was der Nicht-Verwendung entspricht. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\DefaultTOS

7.7.3

IP: Total Length

Im Gegensatz zum Parameter IP Header Length, der nur die Länge des IPHeaders angibt (ohne UDP/TCP und nachfolgende Daten), bezeichnet der Wert von IP Total Length die Länge des IP-Pakets vom Beginn des IP-Headers (Version/Length) bis zum Ende der Nutzdaten. Leere TCP-Pakete enthalten folgende Längenangabe: ■

IP Total Length = 40

Das setzt sich wie folgt zusammen: ■ ■

266

20 Byte entfallen auf den IP-Header. 20 Byte entfallen auf den TCP-Header.

>>> NEW TECH

Im Fokus des Analyzers: IP

Will man also leere TCP-Pakete filtern, tut man dies mit einem Filter auf IP Total Length mit dem Wert 40. Der Längenwert für den IP-Header ist dann ungleich 20, wenn sog. IP Options verwendet werden, etwa IP Record Route oder IP Source Routing. Dass der Längenwert auch zur Kontrolle von TCP-Formatierungen wichtig ist, ergibt sich u.a. in Abschnitt 7.8.5. A. MAC Padding Dies ist für den Empfänger wichtig, um zu wissen, wie viele Daten im Puffer »nach oben« hin (zu TCP, UDP etc.) übergeben werden müssen. Man denke an Ethernet, wo es durchaus geschehen kann, dass ein IP-TCPPaket die Mindestpaketgröße von Ethernet nicht erreicht und der LAN-Frame vom Ethernet-Adapter auf die vorgeschriebenen 64 Byte aufgefüllt wird (Padding). Da Ethernet in der Variante DIX bzw. Ethernet II keine Längenangabe über die Nutzdaten führt, muss IP selber »wissen«, wo die Nutzdaten enden, um das MAC-Padding abtrennen zu können. In Abbildung 7.11 ist eine Gesamtlänge von 1.500 Byte angegeben. Dies ist aus verschiedenen Gründen aufschlussreich:

Abbildung 7.11: IP-Parameter »Total Length« bis »Time To Live«

B. Rückschluss auf die LAN-Physik des Absenders Da die maximale Größe von Nutzdaten, die ein Ethernet-Frame fassen kann, 1.500 Byte beträgt, zeigt dieser Wert indirekt an, dass der Absender über einen Ethernet-Adapter sendet. Im vorliegenden Fall war zwar auch der Analyzer an einem Ethernet-Segment angeschlossen. Aber der Analyzer hätte durchaus an einem Token-Ring oder einem FDDI-Backbone hängen können – dann wäre die Angabe von IP Total Length schon interessant gewesen.

>>> NEW TECH

267

Kapitel 7 • TCP/IP-Grundlagen

Aber auch jetzt bleibt noch ein interessanter Aufschluss an anderer Stelle: C. IP Fragmentation – es fehlten 20 Bytes Zugleich liegt hier ein fragmentiertes Paket vor, wie sich aus den folgenden Werten herauslesen lässt: ■ ■

IP Fragmentation Flags = More Fragments IP Fragment Offset = 1.480 (Byte)

Es muss also bereits mindestes ein IP-Paket vorangegangen sein, dass von den ursprünglichen 1.500 Byte die ersten 1.480 Byte übertragen hat; denn dieses IPPaket setzt genau hier an: Es beginnt bei der Byte-Position 1.480. Das bedeutet, dass – bezogen auf die ursprüngliche Länge von 1.500 Byte – noch ganze 20 Byte übrig bleiben. Nun – jetzt wird es merkwürdig: ■

■

■

IP Fragmentation findet normalerweise nur zwischen Routern statt, nicht zwischen Endgeräten oder zwischen Endgerät und Router. Da der Messpunkt (Endgeräte-Segment oder Backbone) aber unbekannt ist, kann dies hier zunächst nicht bewertet werden. Wenn dieses IP-Paket tatsächlich beim Offset 1.480 ansetzt, um die restlichen Bytes zu senden (1.481 bis 1.500, ganze 20 Byte), so dürfte wohl kaum die Angabe vorhanden sein: IP Fragmentation Flag = More Fragments!? Dies ist ein Widerspruch in sich: Entweder ist es das letzte Paketfragment, dann müsste es heißen Last Fragment, oder es kommen noch More Fragments, dann aber dürfte der Offset wohl kaum kurz vor Ende der Gesamtdatenmenge stehen! Einmal stutzig geworden, schaut man ein zweites Mal hin, und ... es ergibt sich eine physikalische Größe des LAN-Frames von ... MAC Frame Size = 335 Byte Das kann nicht stimmen. Der Ethernet-Header ist 14 Byte lang, der IPHeader 20 Byte, sind zusammen 34 Byte – dann bleiben noch ganze weitere 20 Byte (1.500-1.480=20 Rest-Byte), macht 54 Byte für das IP-Paket. Da es sich aber um einen Ethernet-Frame handelt, der dann auf 64 Byte aufgefüllt wird, würde (müsste) die korrekte Frame-Länge genau 64 Byte betragen. Aber – 335 Byte? Das kann nicht sein. Ein Blick auf den Trace zeigt auch, was da los ist:

D. Defektes IP-Paket Das IP-Paket ist mit vielen anderen Paketen auch zerstört worden; daher erklären sich die unsinnigen, nicht zueinander passenden Werte:

268

>>> NEW TECH

Im Fokus des Analyzers: IP

Abbildung 7.12: Das IP-Paket ist physikalisch zerstört: Überlänge, CRC-Fehler

Der Umstand, dass angebliche Kollisions-Frames (u.a. erkennbar an der ByteFolge 0x555555) ebenfalls länger sind als 64 Bytes (was bei Ethernet-Kollisionen niemals der Fall sein darf!), zeigt, dass hier nicht etwa »echte« Kollisionen für die Verfälschung der Pakete verantwortlich sind. Vermutlich hat ein Router, Switch oder Repeater die Frames künstlich verlängert und/oder mit Kollisionspaketen verschmolzen. Im Ergebnis sehen die Pakete vordergündig so aus, als seien sie Opfer von Ethernet Late Collisions geworden (daher auch der oben im Bild sichtbare Name der Trace-Datei Z_Late_Collision.enf), tatsächlich aber sind dies eben keine Kollisionspakete (eine nähere Durchsicht der Daten zeigt das). Das ist also nun endgültig kein IP-Problem mehr, sondern ein Fehler im Physical Layer. Warum ist dieses kleine Beispiel hier wichtig? 1. Es beweist wieder, dass LAN-Analyse über alle OSI-Schichten gleichzeitig arbeiten muss. Hätten wir weiterhin nur die Netzwerkschicht (Layer 3) mit IP betrachtet, wären wir ganz sicher zu dem Trugschluss gelangt, es läge ein IP-Fehler vor. Das ist eingeschränkt insoweit richtig, wie der IP-Header falsch formatiert ist; aber der IP-Header ist hier Opfer eines Fremdeinflusses. 2. Es ist daher ganz sicher anzunehmen, dass keine eigentliche IP-Komponente beteiligt war: kein IP-Treiber, keine IP Routing Engine. Die Ursache des Fehlers hat mit IP unmittelbar nichts zu tun; die Auswirkung dagegen schon.

>>> NEW TECH

269

Kapitel 7 • TCP/IP-Grundlagen

3. Es beweist darüber hinaus, dass es gut ist, immer mit maximalem Misstrauen an Messdaten heranzugehen: Wo nur irgendetwas vom gesunden Durchschnitt abweicht, muss man genau hinsehen. In diesem Fall war es das Faktum der IP-Fragmentierung an sich, die stutzig machte – weil heutzutage eben kaum noch fragmentiert wird. Die gleichzeitige Betrachung aller maßgeblichen Parameter im Frame, über alle Netzwerkschichten und Protokolle hinweg, hat sich also als Arbeitsprinzip der Analyse bestätigt.

7.7.4

IP: Fragment ID

Mittels der IP Fragment ID (siehe Abbildung 7.11) lassen sich verschiedene Fehler oder Auffälligkeiten feststellen. Hierbei macht man sich zunutze, dass mehrere IP-Pakete desselben Absenders mit derselben IP Fragment ID unterwegs sind. Dass ein IP-Paket zweimal auf derselben Leitung ist (siehe oben, 7.5.3), kann man daran erkennen, dass zwei IP-Pakete dieselbe IP-Paket-Nummer tragen. Für diese Nummer haben sich verschiedene Bezeichnungen eingebürgert: ■ ■ ■

IP Identification IP Packet ID IP Fragment ID

Es gibt LAN-Analysatoren, die das doppelte Auftreten derselben IP Fragment ID automatisch erkennen. (Der Autor arbeitet hier mit dem LANdecoder32 von Triticom, siehe Abbildung 7.13.) Die IP Fragment IDs verwenden einen Zwei-Byte-Zähler (0-65535), der von Paket zu Paket vom Treiber jeweils um 1 erhöht wird, und zwar ungeachtet der IP-Adresse des/der Adressaten. Die IP Fragment IDs werden also nicht je Dialog getrennt hochgezählt, sondern über alle IP-Pakete hinweg, ungeachtet der Paarbeziehungen in den Dialogen. Sollten TCP-Pakete in Wiederholung übertragen werden, wird gleichwohl im IP-Header hochgezählt: IP selber kennt keine Wiederholungen, darum können (dürfen) bei IP auch keine zwei Header identisch sein; dies ist bei TCP anders. Der Mechanismus der IP-Fragmentierung steht in einem engen Zusammenhang mit dem Aushandeln der TCP Maximum Segment Size (siehe 7.8.9). A. Doppelte IP Fragment IDs bei Local Loop/Local Routing Wird ein IP-Paket von einem Router in dasselbe LAN-Segment zurückgeschickt, aus dem er es erhalten hat (Rx und Tx über denselben Router-Port), so bezeichnet man das als: ■

270

IP Local Loop >>> NEW TECH

Im Fokus des Analyzers: IP

■ ■

IP Local Routing Die Erkennung dieses Phänomens sollte durch automatische Routinen des Analyzers erfolgen (Experten-System), etwa wie in Abbildung 7.13 zu sehen.

Abbildung 7.13: Automatische Erkennung von Local IP Loops durch ein Expertensystem

Das einschlägige Szenario wurde bereits im Abschitt 7.5.3 samt der zugehörigen Router-Meldung »ICMP: Redirection« behandelt. Es muss sich hierbei nicht zwingend um einen Fehler handeln; es kann sich auch um eine durchaus gewollte Anordnung der IP-Teilnehmer handeln. Dies entscheidet sich letztlich an der vorliegenden Dokumentation. B. Doppelte IP Fragment IDs bei MAC-ReTx MAC-Retransmissions (ReTx) von IP-Paketen: Anders sieht es aus, wenn ein LAN-Adapter eine erste Übertragung des IPPaketes mit Fehlerstatus beendet und das Paket aus seinem Sendepuffer heraus noch einmal schickt. Bei Ethernet kann dieser Fall eintreten, wenn während des Sendens die SQEBedingung eintritt (SQE: Signal Quality Error). Bei Token-Ring kann dieser Fall eintreten, wenn ein interner Adapterfehler zum Abbruch führt, was sofort mit der sog. Abort Sequence quittiert wird. Sollte der LAN-Adapter also den Fehlerzustand erkennen, wird er nach seinen eigenen Regeln warten, bis er erneut senden kann, und dann den immer noch im Sendepuffer vorhandenen LAN-Frame senden.

>>> NEW TECH

271

Kapitel 7 • TCP/IP-Grundlagen

In diesem Falle geht das Ereignis völlig an den Treibern der höheren Schichten vorbei, da sich alles nur in der Hardware des LAN-Adapters abspielt. Darum kann es sein, dass zwei (oder mehrere) IP-Pakete mit identischer IP Fragment ID unterwegs sind. Sehr wahrscheinlich werden sich diese Frames dann aber durch unterschiedliche physikalische Frame-Größen unterscheiden: Erst das letzte Paket wird die volle Größe haben, während die vorherigen kleiner sein dürften, da ihre Übertragung ja wegen des Eintritts einer Fehlerbedingung abgebrochen worden war. C. Microsoft zählt nur im Hi-Byte Microsoft-Maschinen haben die interessante Angewohnheit, die IP Fragment ID immer um den Wert von 256 (0x0100) hochzuzählen, da die Programmierer nur das Hi-Byte hochzählen, nicht aber das Lo-Byte. Es wird also wie folgt gezählt: 0x0100, 0x0200, 0x0300, und nicht etwa: 0x0001, 0x0002, 0x0003, wie es richtig wäre. Das gilt nur für Windows 3.x, Windows 9.x und NT. Vermutlich hängt dies damit zusammen, dass im Client-Server-Protokoll von Microsoft und IBM, dem Server Message Block (SMB), mit verdrehten Lo/HiBytes gearbeitet wird. Da also das höherwertige Byte zum Zählen verwendet wird, und nicht das niederwertige Byte, springt der Zähler in der Dezimaldarstellung eben immer um ganze »256« weiter statt nur um »1«. Dies ist außerordentlich lästig, weil es somit praktisch unmöglich wird, die Sendehäufigkeit eines fernen Servers einzuschätzen. Beispiel: Erhält ein lokaler Client von einem fernen Server IP-Pakete mit den IP Fragment IDs 1.702, 1.705, 1.706, 1.707, 1.710, 1.712, 1.715, .., .., so ist klar, dass er sich den Server mit nur wenigen anderen teilt: Der Server sendet kaum Pakete an andere Empfänger.

Abbildung 7.14: MS-Zählung der IP Fragment ID: 0xF837 > 0xF937

272

>>> NEW TECH

Im Fokus des Analyzers: IP

Springt die ID-Folge jedoch wild herum: 25.109, 26.223, 26.967, 27.418, .., .., so fällt es schon deutlich schwerer, daraus die richtigen Schlüsse zu ziehen. Praktisch ist es unmöglich, damit noch etwas anzufangen. Die Abbildung 7.14 zeigt zwei unmittelbar aufeinander folgende IP-Pakete des selben Absenders – und die beiden Werte für die IP Fragment ID: Paket # 20 – IP Fragment ID = 63543 = 0xF837 Paket # 21 – IP Fragment ID = 63799 = 0xF937

Hier ist deutlich zu erkennen, dass nur im Hi-Byte gezählt wird, nicht aber im Lo-Byte: Die Differenz beider ID-Werte beträgt genau 256 bzw. 0x0100.

7.7.5

IP: Fragmentation Flags

Die sog. IP Fragmentation Flags erfüllen zwei Funktionen (siehe Abbildung 7.11): ■

■

Der Absender teilt den Routern mit, ob fragmentiert werden darf (oder nicht): May Fragment/Don’t Fragment Der fragmentierende Router teilt mit, ob das aktuelle Fragment das letzte Fragment des ursprünglichen IP-Pakets ist (oder nicht): More Fragments/Last (Only) Fragment

Auch hier muss genau hingesehen werden: Der Absender verbietet die Fragmentierung: »Don’t Fragment« Oft wird vom Absender die IP-Fragmentierung verboten, obwohl sie im aktuellen Fall nötig wäre. Die »klassische Falle«, in die man hier laufen kann, sieht wie folgt aus: Ein Unternehmen hat mehrere Betriebsstätten (Filialen), die über IP verbunden sind. Vor langen Jahren wurde das erste WAN eingerichtet mittels X.25 (IP over X.25), das auf eine geringe Paketgröße eingestellt wurde (jedenfalls kleiner 1.500 Byte). Später wurde dann aufgerüstet und über ISDN gearbeitet. Dabei ließ man die X.25-Strecken bestehen, um sie als Ersatzwege zur redundanten Auslegung des Corporate Networks zu verwenden. Seither ist die Zahl der Client-PCs und Applikationen massiv angestiegen. Und niemand hat etwas bemerkt. Niemand hat durch Messungen festgestellt, dass viele der neuen Applikationen den IP-Treiber so parametrisieren, dass dieser in die IP-Pakete den Stempel Don’t Fragment setzt.

>>> NEW TECH

273

Kapitel 7 • TCP/IP-Grundlagen

Da über die ISDN-Strecken ohne IP Fragmenting gearbeitet wird (auch das Invers-Multiplexing bei S2M-Routern bleibt für IP transparent, da es in der Hardware des Multiplexers stattfindet), fällt niemandem auf, dass die IPPakete mit »Don’t Fragment« auf die Reise gehen. Dann, eines Tages, bricht die S2M-Schnittstelle zusammen, und der Router schaltet auf die X.25-Verbindung um. Und, was passiert? Massenhaft brechen jetzt auch die IP-Sessions zusammen – jedenfalls die ClientServer-Sessions, die mit großen IP-Paketen arbeiten, während die SNA-Sessions weiterlaufen: sie arbeiten mit so kleinen Datenmengen, dass sie unfragmentiert über die X.25-Strecke gebracht werden können. Jetzt geht die Suche los – alle verdächtigen das X.25-Netz. Auf das Nächstliegende kommt niemand: ■ ■

Dass nämlich schlicht die IP-Teilnehmer dem Router (schon immer!) das Fragmentieren ihrer IP-Pakete verbieten. Dass die Rückmeldungen des Routers mit »ICMP: Fragmentation Needed« von den Client-PCs völlig unberücksichtigt bleiben – sie senden weiter ihre Pakete mit »IP: Don’t Fragment« auf die Reise.

Darum: laufend messen! Auch dieses Beispiel stützt wieder das Credo des Autors: Nicht erst messen, wenn es kracht – denn in der Panik kommt man oft nicht auf den richtigen Gedanken! Messen Sie, wenn noch Zeit dazu ist! Am besten täglich, sofern sie mit Routing und verschiedenen IP-Subnetzen arbeiten. Registry muss ggf. manuell eingestellt werden WinNT-Rechner können sich bei fortlaufenden Paketverlusten, die auf zu großen Paketlängen beruhen, einstellen – diese Fähigkeit ist jedoch per Vorgabe auf AUS gestellt! Die sog. »Black Hole Detection« -das Erkennen »schwarzer Löcher« auf der Datenstrecke- muss manuell auf EIN gestellt werden! WinNT Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\Options\ Option# (22,24,25,26) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\MTU HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ EnablePMTUBHDetect HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ EnablePMTUDiscovery

274

>>> NEW TECH

Im Fokus des Analyzers: IP

7.7.6

IP: Fragment Offset

Wird ein IP-Paket fragmentiert, wird in jedes Fragment eine Kopie des ursprünglichen IP-Headers gelegt; dieser wird IP Fragmentation Header genannt (siehe Abbildung 7.11). Ob das letzte Fragment erreicht ist, ergibt sich aus zwei Merkmalen: ■ ■

Das IP Fragmentation Flag zeigt an: »Last Fragment«. Die Paketlänge auf MAC Layer sowie der IP Fragment Offset ergeben bei entsprechender Verrechnung, dass die Gesamtlänge des ursprünglichen (unfragmentierten) IP-Paketes erreicht ist.

Der sog. IP Fragment Offset gibt an, ab welcher Position des ursprünglichen IP-Paketes das vorliegende IP-Fragment gebildet wurde. Das erste IP-Fragment eines zerlegten IP-Paketes trägt darum immer den Wert »0«. Es mag zwar rein theoretisch erscheinen: Aber dass der Wert von IP Fragment Offset nur noch wenig kleiner ist als der Wert für die Gesamtlänge des ursprünglichen IP-Paketes (IP Total Length), muss nicht notwendig besagen, dass es nun auch schon das letzte Fragment wäre. Richtig ist, dass dies normalerweise so wäre; aber schon das Beispiel im Abschnitt 7.7.3 hat gezeigt, dass immer Vorsicht geboten ist. Ein gesundes Misstrauen zahlt sich über die Dauer immer aus.

7.7.7

IP: Time To Live (TTL)

Es kann immer sein, dass IP-Pakete von Routern verworfen werden, weil ihr Hop Credit zu Ende ging (siehe Abbildung 7.11): In einem solchen Fall war ■ ■ ■

der TTL-Wert des Absenders unzureichend gering, der Verkehrsweg zu lang bzw. die Zahl der Router zu groß, der aufsummierte Wert aller Cost/Metric-Werte zu hoch.

Jeder Router hat die Pflicht, den TTL-Wert eines jeden durchlaufenden IPPaketes um den Wert von mindestens »1« zu vermindern. WinNT Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\Options\ Option# (37 = Default TTL Option) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\DefaultTTL

Der TTL-Vorgabewert ist jedoch nur von minderer Bedeutung, da die Applikationen bzw. höheren Treiber jederzeit einen anderen Wert setzen können (siehe unten).

>>> NEW TECH

275

Kapitel 7 • TCP/IP-Grundlagen

A. IP-Pakete mit TTL=0 werden verworfen Fällt der TTL-Wert eines IP-Pakets bei einem Router auf »0«, wird das IP-Paket verworfen und an den Absender Rückmeldung gegeben mit »ICMP: Time Exceeded/TTL Decreased To Zero« (siehe 7.6.3). Wenn ein Router ein IP-Paket wegen TTL=0 verwirft, muss dies nicht bedeuten, dass die Zahl der Router, die das IP-Paket querte, mit dem TTL-Ausgangswert identisch gewesen wäre. B. Router Cost/Metric: Reisekosten Dies ergibt sich daraus, dass jeder Router über den Parameter Cost (oder Metric) angewiesen werden kann, den TTL-Wert der durchlaufenden IP-Pakete um mehr als »1« zu vermindern. Diese Funktion war früher einmal eine Möglichkeit, besonders wichtige Router von IP-Verkehr weitgehend frei zu halten, solange noch andere Strecken zur Verfügung standen: IP-Router wählen unter verschiedenen Wegen in aller Regel den aus, der den geringsten Hop Count aufweist – wobei aber eben der mit den Routing-Tabellen unter den Routern ausgetauschte Hop Count eigentlich ein aufsummierter Cost Count bzw. Metric Count ist. Auf alten Unix-Routern wurde dieser Wert bei statischen Routen in der folgenden Config-Datei angegeben: /etc/gateways

C. Wechselnde TTL-Werte desselben Absenders Da nicht der IP-Treiber allein, sondern auch die darüber arbeitende Applikationen über den vorgegebenen TTL-Wert entscheiden, und da deswegen die TTL-Werte oft sogar beim selben IP-Teilnehmer sehr uneinheitlich sind, muss man oft zweimal hinsehen. Üblicherweise werden die folgenden TTL-Werte verwendet: TTL = 16(0x10), 32(0x20), 64(0x40), 128(0x80), 255(0xFF).

Allerdings können seitens des IP-Senders beliebige TTL-Werte verwendet werden. Dies alles ist keine akademische Spurensuche, sondern wichtige Statistik, da sie Routing-Fehler offenbaren kann. Ein Beispiel: D. Routing-Fehler (1) Die Pakete eines auswärtigen IP-Absenders zeichnen sich wie folgt aus: ■ ■

276

Die IP-Pakete sind mal zu sehen mit TTL=62, dann mal mit TTL=61, dann wieder mit TTL=62 und so fort. Die IP Fragment ID wird laufend hochgezählt.

>>> NEW TECH

Im Fokus des Analyzers: IP

Dies lässt nur eine Deutung zu: Die Pakete wurden mit TTL=64 losgeschickt und liefen mal über zwei, mal über drei Router (64-2=62/64-3=61). Die Pakete nehmen also laufend wechselnde Wege. Dies kann dann ein Hinweis auf Instabilitäten im Router-Backbone sein, aber auch auf mögliche Fehler in den Routing-Tables bzw. Routing-Algorithmen. E. Routing-Fehler (2) Die Pakete eines lokalen IP-Absenders zeichnen sich wie folgt aus: ■ ■

Die IP-Pakete sind mal zu sehen mit TTL=64, dann mal mit TTL=63, dann wieder mit TTL=64 und so fort. Die IP Fragment ID ist immer in je zwei IP-Paketen identisch.

Dies lässt nur eine Deutung zu: Die Pakete wurden mit TTL=64 losgeschickt, treffen im lokalen LAN-Segment auf einen Router, der schickt sie in dasselbe LAN-Segment zurück und zählt dabei korrekt den TTL-Wert um »1« herunter, da es sich um einen regulären Routing-Vorgang handelt: Die IP-Pakete durchlaufen einen sog. Local Loop (siehe Abschnitt 7.5.3). F. Routing-Fehler (3) In Anlehnung an das Beispiel im Abschnitt 7.7.5 kann folgendes Szenario zum Doppel-Crash führen: Früher wurde über ein WAN »A« älterer Technik gearbeitet; später wurde umgerüstet auf WAN »B«, wobei WAN »A« als Ersatzweg zur Redundanz bestehen blieb. Alle freuten sich, dass mit dem neueren WAN »B« sogar die Zahl der RouterHops verringert und somit alles schneller wurde. Dann wuchs das Netz über Jahre munter vor sich hin und nichts passierte. Dann, eines Tages, fällt WAN »B« aus und die Router schalten um auf WAN »A«. Und? Nichts geht mehr. Warum? Inzwischen war eine Vielzahl von Applikationen eingeführt worden, die ihre IPPakete nur mit geringen TTL-Werten ausstatten (TTL=16). Der Ersatzweg aber ist so angelegt, dass TTL=16 als Hop Credit nicht mehr ausreicht. Das muss nicht bedeuten, dass es mehr als 16 Router wären; schließlich kann jeder Router über den Wert Cost (oder Metric) angewiesen werden, den TTLWert der durchlaufenden IP-Pakete um mehr als »1« zu vermindern! Diese Funktion war früher einmal eine Möglichkeit, besonders wichtige Router von IP-Verkehr weitgehend frei zu halten, solange noch andere Strecken zur Verfügung standen: IP-Router wählen unter verschiedenen Wegen in aller Regel den aus, der den geringsten Hop Count aufweist – wobei aber eben der mit den Routing-Tabellen unter den Routern ausgetauschte Hop Count eigentlich ein aufsummierter Cost Count bzw. Metric Count ist.

>>> NEW TECH

277

Kapitel 7 • TCP/IP-Grundlagen

Reihenweise brechen die IP-Pakete zusammen mit TTL=0 bei einem der WANRouter, der auch artig mit der Rückmeldung »ICMP: Time Exceeded/ReAssembly Timer Expired« (siehe 7.6.4) anzeigt, dass die IP-Teilnehmer doch bitte den TTL-Wert erhöhen mögen. Die merken aber mal wieder nichts und melden: »Von Gerät Netzwerk kann nicht gelesen werden.« Das war’s dann mal wieder. G. IP Multicasts (Cisco) mit TTL=0 Es gibt IP-Multicast-Pakete, so von Cisco-Routern, adressiert an 224.0.x.x, die den Wert TTL=0 haben. Das ist normal und kein Anlass zur Sorge.

7.7.8

IP: Protocol

Die Angabe des im Paket hinter dem IP-Header liegenden Protokolls ist als unkritisch anzusehen. Die Wahrscheinlichkeit, dass sich hiermit ein Fehler verbindet, geht gegen Null.

Abbildung 7.15: IP-Parameter »Fragment Offset« bis »Destination Address«

Auf Unix-Rechnern entspricht diesem IP-Parameter eine Config-Datei: /etc/protocols

Bei MS-Windows-Rechnern werden grundsätzlich zunächst einmal alle Protokolle oberhalb von IP empfangen und verarbeitet. Es können aber aus Sicherheitsgründen Einschränkungen definiert werden. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\RawIPAllowedProtocols HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ EnableSecurityFilters

278

>>> NEW TECH

Im Fokus des Analyzers: IP

7.7.9

IP: Checksum

Die IP-Prüfsumme wird von jedem Router neu berechnet, da ja jeder Router den TTL-Wert zu vermindern hat. Als die Router noch umgebaute Unix-Rechner waren, fand dieser Prozess in der Software statt und belastete zusätzlich die CPU. Die heutigen Hardware-Router leiden darunter kaum noch. Die sog. Layer-3-Switches (die moderne Variante der BRouter = Bridge/Router) haben heute den zusätzlichen Vorzug, dass sie auf dem lokalen Campus (bei ATM und MPOA auch im WAN) die Zahl der IP Router Hops verringern können, bestenfalls auf nur noch 1 Hop.

7.7.10 IP: Source/Destination Address Die IP-Adressen von Sender und Absender dürfen als gegeben angenommen werden; Fehler sind in der manuellen Konfiguration der Rechner oder in Verfahren wie RARP, BOOTP oder DHCP zu suchen. Die Auswirkungen von falsch eingestellten IP-Adressen aber werden in der IPAnalyse sichtbar.

Abbildung 7.16: IP-Parameter »Source Address« und »Destination Address«

A. Filter auf IP-Adressen Viele Analyzer bieten vorgefertigte Filter für IP-Adressen an, etwa wie in Abbildung 7.17 dargestellt. Diese Filter sind zwar leicht anzuwenden, haben aber einen systematisch unverzeihlichen Nachteil: Sie suchen nur nach diesen Adressen im IP-Header, nirgends sonst. Davon ist messtechnisch bzw. aus analytischer Sicht dringend abzuraten! >>> NEW TECH

279

Kapitel 7 • TCP/IP-Grundlagen

Abbildung 7.17: Filter auf IP-Adressen (im IP-Header)

Es gibt viele wichtige Pakete mit der gesuchten IP-Adresse, die gar nicht von einem solchen Filter erfasst würden, weil bzw. sofern die gesuchte IP-Adresse im Datenteil auftaucht! Dazu gehören etwa: ■ ■ ■ ■ ■ ■

ARP-Requests (Replies scheiden hier aus) BOOTP-Requests & -Replies IMCP-Meldungen (insbesondere solche, die Paketverwerfung melden!!) DNS-Requests & -Replies WINS-Requests & Replies NetWare-IP (IP over IPX)

Abbildung 7.18: Filter auf den Hex-Code einer IP-Adresse (ohne festen Offset)

Es ist daher unbedingt erforderlich, dass auf IP-Adressen nur »wilde Filter« gesetzt werden, die keinen festen Offset verwenden, sondern die Hex-Folge der IP-Adresse überall in den Paketen suchen, wie ihn Abbildung 7.18 zu sehen.

280

>>> NEW TECH

Im Fokus des Analyzers: IP

Im Falle der Abbildung 7.18 wurde durch den Analyzer die markierte IPAdresse als Hex-Code gleich in das Filterfenster übernommen; es brauchte dann nur noch die Offset-Angabe 0x0022 ersetzt zu werden durch die Angabe Anywhere in Frame. Jetzt erst kann man sicher sein, alle Pakete zu sehen, die mit einer Maschine zu tun haben (könnten). Das geht so weit, dass durchaus auch Pakete zu sehen sein könnten, die unmittelbar überhaupt nichts mit der gesuchten Maschine zu tun haben, z.B. dann, wenn eine Maschine kleine Ethernet-Pakete mit zufälligen Speicherdaten auf die Mindestlänge von 64 Byte auffüllt und eben zufällig die gesuchte IP-Adresse darunter ist. Aber selbst das kann in Einzelfällen noch aufschlussreich sein. B. Doppelte IP-Adressen Wird eine IP-Adresse von zwei oder mehr Stationen gleichzeitig verwendet, führt dies sehr wahrscheinlich zu schweren Fehlern (Session-Abbrüchen etc.). Dieser Fehler war in der Vergangenheit praktisch schon übliche Erscheinungsform manueller Einrichtung von IP-Treibern: Von einer Musterdiskette wurden noch zu alten DOS-Tagen die Treiber samt Config-Dateien auf den PC kopiert, und dann wurde eben schon mal vergessen, die IP-Adresse gemäß Subnet und Schema anzupassen.

Abbildung 7.19: Doppelte IP-Adresse (LANreport32 Expertendiagnose)

In Zeiten von DHCP wird dieser Fehler immer seltener. Viele Analyzer erkennen doppelte IP-Adressen automatisch. Es sollte also nicht schwer sein, einen solchen Fehler zu erkennen.

>>> NEW TECH

281

Kapitel 7 • TCP/IP-Grundlagen

C. IP-Adresse im falschen Subnet Aus dem gleichen Grund (manuelle Konfiguration) wurde oft entweder bei richtiger Subnet-Mask eine falsche IP-Adresse vergeben, oder bei richter IPAdresse eine falsche Subnet-Mask. Dies geschah oft sogar ohne einen Eingriff in die Konfiguration des Rechners selber, sondern durch Umzug des Mitarbeiters samt seines Rechners in eine andere Abteilung und damit in ein anderes physikalisches LAN-Segment sowie deshalb in ein anderes logisches IP-Subnetz. Die Folge war, dass ein IP-Teilnehmer nicht über den nächsten Router hinauskam und somit keinen Kontakt zu seinem Server fand. Auch diese Fehler sind nun seltener geworden, seitdem DHCP immer häufiger verwendet wird, aber auch Layer-3-Switches bzw. VLAN-Switches auf dem lokalen Campus eingesetzt werden (statt herkömmlicher Router). D. IP-Broadcast-Adresse ist falsch/falsche IP Subnet Mask Ist bei einem IP-Teilnehmer die IP Subnet Mask falsch eingestellt, führt dies zu einer fehlerhaften IP Subnet Broadcast Address. Die Folgen sind (wahlweise, je nach Fehler): 1. Der Broadcast wird als solcher von den Subnetz-Teilnehmern nicht erkannt, weil zu wenige Adress-Bits auf »1« gesetzt sind. 2. Der Broadcast wird zwar als solcher von allen Subnetz-Teilnehmern erkannt, wird aber über das lokale Subnetz hinaus in fremde IP-Netze gestreut, weil zu viele Adress-Bits auf »1« gesetzt sind. Das Szenario (1) ist verhältnismäßig simpel zu erkennen: Der Anwender an der falsch eingestellten Maschine kann vom ersten Moment an nicht korrekt arbeiten; hier also wird der Fehler schnell entdeckt. Das Szenario (2) ist deswegen etwas vertrackt, weil die Anwender möglicherweise zunächst normal arbeiten können; die Auswirkungen sind ggf. wie folgt: ■ ■

Die Subnetze werden nach und nach mit immer mehr Multicasts bzw. Broadcasts geflutet. Es antworten z.B. Server (DHCP, DNS, WINS) auf Broadcasts, deren Antwort nicht erwünscht ist. Dies kann zu schwerwiegenden Fehlern während der Initialisierungsphase (Boot-Phase) führen.

Mit die gravierendsten Fehler treten in der Tat auf, wenn durch unbedachte Broadcasts DHCP-Server und WINS-Server antworten, die für das lokale Subnetz gar nicht zuständig sind. Zwar darf allgemein angenommen werden, dass lokale Server schneller antworten als weiter entfernt stehende Server; das Risiko schwerer Fehler aber ist immens hoch. Das Vertrackte an diesem Fehler besteht schlicht in dem Unterschied zum herkömmlichen Szenario, dass eben gar kein DHCP/WINS/DNS-Server antwortet:

282

>>> NEW TECH

Im Fokus des Analyzers: IP

Ein solches Szenario fällt einfach mehr auf und ist schneller erkannt und behoben. Es sei auf den Abschnitt 7.4.4 verwiesen. WinNT Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\Options\ Option# HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\Options\ 27 (=All subnets are local) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\.. ..\DhcpIPAddress ..\DhcpServer ..\DhcpSubnetMask ..\DhcpSubnetMaskOpt ..\EnableDhcp ..\IPAddress ..\UseZeroBroadcast

7.7.11 IP Expertendiagnose Viele der gängigen IP-Fehler können durch automatische Auswertungen erkannt werden. Programme wie Sniffer (NAI), Observer (Network Instruments), LANdecoder32 (Triticom), Surveyor (Shomiti), NetSense (Net3Group), LANreport (Synapse) verfügen über entsprechende Fähigkeiten.

Abbildung 7.20: Expertendiagnose von IP (hier: LANdecoder32)

>>> NEW TECH

283

Kapitel 7 • TCP/IP-Grundlagen

Gleichwohl muss gewarnt werden: Keines dieser Programme ist in der Lage, alle die genannten Fehler zu erkennen oder sinnvoll darzustellen. Auch gilt, dass jedes Programm einen anderen Blick auf die Daten hat; im Grunde müsste sich der Analyst jedes dieser Programme anschaffen, um möglichst viele Fehler abzudekken und Darstellungsformen zu haben. Die Zusammenfassungen, die in Abbildung 7.20 unten zu sehen sind, hängen von Einstellungen ab, die zuvor hinterlegt wurden.

Abbildung 7.21: IP Expertenanalyse: Definition von Schwellwerten zur Qualitätssicherung

Über Schwellwerte wie die hier in Abbildung 7.21 kann genau gesteuert werden, wie viel Fehlertoleranz man selber akzeptieren möchte. So würde man bei WAN-Verbindungen alle Fehlerklassen untersuchen, bei LAN-Verkehr vielleicht nicht unbedingt.

7.7.12 IP und NetBIOS Seit einigen Jahren lässt Microsoft sein NetBIOS nicht mehr nur über das Layer2-Protokoll LLC, sondern auch über die Layer-3-Protokolle IP und IPX laufen, was dazu führt, dass es Bedarf gibt an der Auflösung von NetBIOS-Namen (Rechner-Namen, Workgroup-Namen, Domain-Namen) in IP-Adressen. Die hierzu entwickelten Treiber arbeiten teilweise sehr eigenwillig. So kann immer wieder beobachtet werden, dass ein Win95/98/NT-Rechner beispielsweise auf die Idee kommt (hier: ein Win95-Rechner), eine im Campus-LAN

284

>>> NEW TECH

Im Fokus des Analyzers: IP

vorhandene NetBIOS-Workgroup namens »Win95« zum Anlass zu nehmen, im Internet (!!) nach DNS-Servern zu suchen, die wohl die Adresse www.win95.de in die zugehörige IP-Adresse aufzulösen vermögen (!!). Wie das? Microsoft hat versucht die maximale Connectivity sicherzustellen, was an sich eine gute Idee ist. Dies führt aber im Einzelfall dazu, dass Folgendes geschieht (Beispiel): ■

Ein NetBIOS-Rechner soll gefunden werden.

■

Es wird ein NetBIOS-Broadcast gesendet; es kommt keine Antwort.

■

Daraufhin wird der WINS-Server gefragt; der weiß auch nichts.

■

Daraufhin wird jeder nur irgendwie greifbare DNS-Server gefragt – auch dann, wenn dieser im Internet steht und eigentlich damit gar nichts zu tun hat; – auch dann, wenn die Namensauflösung via DNS ausdrücklich auf AUS gestellt wurde!

■

Am Ende wird über alle verfügbaren Protokolle gesucht, etwa IPX.

Das Beispiel lässt sich auch anders sehen: Nehmen wir an, Sie waren mit Ihrem Laptop gestern noch bei einem Kunden und haben auf dessen Server zugegriffen, der über LLC-IPX arbeitet. Heute sind Sie zurück in Ihrem Hause, und dort wird nur mit IP gearbeitet. Was tut Ihr Laptop? Er »erinnert« sich an alle Server, auf die er »kürzlich« Zugriff hatte (in der Registy unter Recent abgelegt), und tut Folgendes: ■

Der Laptop sucht mit IPX-Broadcasts nach dem NetWare-Server. Niemand antwortet (klar, der Server existiert ja nur in einem ganz anderen Netz).

■

Jetzt wird das Protokollspektrum voll ausgereizt: Neben LLC-IPX-Broadcasts werden nun auch welche gesendet mit Ethernet-II-IPX, LLC-SNAPIPX, Raw-Ethernet-IPX. Niemand antwortet.

■

Da die Versuche über IPX nicht fruchteten, entschließt sich der Laptop, es mal mit NetBIOS zu versuchen; könnte ja sein, dass der NetWare-Server über Nacht umgebaut wurde zu einem (oder ersetzt wurde durch einen) Mircosoft-Rechner:

■

NetBIOS-Broadcasts über LLC, IPX, IP – keine Antwort.

■

WINS-Anfragen – keine Antwort. DNS-Anfragen – keine Antwort.

■

Wenn der DNS-Server im Internet steht, wird eben auch ins Internet abgefragt. Das grenzt an blanken Unsinn – und doch muss diesem Verfahren ein akzeptabler Sinn zugesprochen werden, denn tatsächlich wird über diesen Mechanismus sichergestellt, dass auch bei verschiedenen falschen Konfigurationen noch Rechner im Netz gefunden werden. Es mag auch eine Rolle für Microsoft ■

>>> NEW TECH

285

Kapitel 7 • TCP/IP-Grundlagen

gespielt haben, dass hierdurch die Migration seitens der Kunden von NetWareIPX-Servern zu NetWare-IP-Servern oder Micorosft-NT-Servern (IP, NetBIOS) erheblich unterstützt wird. Wenn aber das Ganze dazu führt, dass sogar Ihr Laptop – um im Beispiel zu bleiben – bei Ihnen zu Hause, wenn Sie privat im Internet surfen, im Rechenzentrum Ihres Providers per WINS-Broadcasts bzw. mit dem Versuch einer NetBIOS-Namensauflösung nach den Servern sucht, die eigentlich nur bei Ihnen im Büro stehen, und dies, obwohl sie in der Systemsteuerung ausdrücklich die Namensauflösung via WINS untersagt haben (!!), dann hört der Spaß langsam auf. Am Ende artet das Ganze in völlige Verwirrung aus: So konnten MicrosoftRechner dabei beobachtet werden, Internet-Router, die ICMP-Meldungen aus fernen Ländern zurückgaben, für DNS-Server zu halten und um NetBIOSNamensauflösung zu bitten – bzw. sie zu fragen, ob sie dies denn wohl könnten! Der durchaus lobenswerte Versuch von Microsoft, möglichst große Connectivity und Usablility zu schaffen, führt zu erheblichen und unerwünschten Nebeneffekten, die wesentlich aus dem Zwang herrührt, zu alten Protokollen (NetBEUI) und fremden Protokollen (IPX) und fremden Architekturen (DNS) kompatibel sein zu müssen. Auch resultieren solche Fehler oft daher, dass fremde Treiber installiert werden, etwa der 32-Bit-Client von NetWare. Hier soll nicht ungerecht gescholten werden – es soll klar gemacht werden, dass rund um den Versuch von Microsoft, IP als Standardprotokoll einzusetzen, erhebliche Folgeerscheinungen und Fehler eingetreten sind, deren Bereinigung sicher noch Jahre brauchen wird, und die den LAN-Analysten erheblich beschäftigen. Auch hier gilt: Es muss laufend über alle sieben OSI-Schichten geprüft werden, alles links und rechts muss mitgenommen werden: Eine Analyse, die sich nur auf eine Schicht beschränkt (nur Layer 3, nicht auch Layer 2 etc.) oder nur auf ein Protokoll (nur IP, nicht IPX) oder nur auf einen Dienst (Beipiel: nur WINS, ohne DNS), greift völlig ins Leere. Ansonsten sei auf den Abschnitt NetBIOS verwiesen.

7.8 Im Fokus des Analyzers: TCP Konfigurationsfehler sind bei TCP eher eine Seltenheit. Wenn hier nach Fehlern gesucht wird, so sind dies eher Reaktionen der TCP-Treiber auf bestimmte Zustände im Netzwerk (Stau, Paketverluste, Timeouts). Zur besseren Übersicht sein ein TCP-Paket vorangestellt.

286

>>> NEW TECH

Im Fokus des Analyzers: TCP

Abbildung 7.22: TCP Header im LANdecoder32 (davor: der IP Header)

TCP ist angesichts des Umstandes, dass wir in diesem Text über »Netzwerkanalyse« sprechen, nicht direkt der richtige Ansprechpartner, denn die üblichen Netzwerkkomponenten kümmern sich nicht um TCP – Repeater, Bridges, Switches, Router werten TCP nicht aus (von Firewall-Systemen abgesehen). TCP aber reagiert auf Fehler des Netzwerksystems; Fehler der Layer 1-3 werden also durchaus in den Reaktionen von TCP indirekt sichtbar. Auch Fehler auf Applikationsebene können ihre »Fingerabdrücke« im TCP-Datenstrom hinterlassen. Dies ist im Gegensatz dazu bei UDP (User Datagram Protocol) nicht so, weil es ein um alle logischen Fähigkeiten beraubtes TCP ist und verbindungslos arbeitet, also ohne jede Data Flow Control. UDP lässt also nicht solche Aufschlüsse zu wie TCP. UDP wird verwendet bei Übertragungen, die keiner Sicherung bzw. Datenfluss-Steuerung bedürfen, oder bei denen diese Sicherung auch nicht sinnvoll einsetzbar wäre, etwa IP-Broadcasts.

7.8.1

Das Prinzip der TCP Data Flow Control

Die Grundgedanken, die TCP und seiner Art der Datenfluss-Steuerung zugrunde gelegt wurden, waren:

>>> NEW TECH

287

Kapitel 7 • TCP/IP-Grundlagen

■

■

■

■

■

■

■

288

Bi-direktionaler Datenaustausch Innerhalb einer TCP-Verbindung soll die Datenkommunikation bi-direktional möglich sein. Während nämlich Funktionen wie File Transfer nur unidirektional sind, verläuft Inter Process Communication (IPC) oft zweiseitig. Offset-Kennungen Ähnlich dem bereits besprochenen Fragmentation Offset bei IP werden die Offset-Kennungen bei TCP verwendet: Mit der Sequence Number wird die Position im Sendestrom, mit der Acknowledge Number die Position im Empfangsstrom dargestellt. Sequence Number (SEQ) Der jeweilige Sender des TCP-Paketes teilt mit der Sequence Number mit, an welcher Stelle (Byte-Position) des zu übertragenden Datenstromes dieses TCP-Paket beginnt (bzw. die nachfolgenden Nutzdaten beginnen). Jede Teilmenge der zu übertragenden Nutzdaten wird in der Sprache von TCP Sequence genannt; daher wird das Zerteilen der Nutzdaten auf Paketgröße nicht Paketierung, sondern Sequenzierung genannt. Acknowledge Number (ACK) Gleichzeitig bestätigt der Sender des TCP-Paketes den Erhalt der Daten, die er von der Gegenstelle bereits fehlerfrei und lückenlos erhalten hat, mittels der Acknowledge Number. Zusatz-Offset – streng geheim! Wohl nur aus den Bedingungen des Kalten Krieges und dem Faktum, dass TCP/IP für das US-Militär geschaffen wurde, ist zu erklären, warum bei einem Verbindungsaufbau nicht etwa beide TCP-Teilnehmer jeweils beim Offset von »0« zu senden beginnen. Auf beiden Seiten wird zu Beginn des Verbindungsaufbaus zum tatsächlichen Offset »0« eine Zufallszahl hinzuaddiert. Diese teilen sich beide TCPTeilnehmer zu Beginn der Session mit. Auf beiden Seiten muss diese dann bei Erhalt von TCP-Paketen wieder von der im TCP-Header stehenden Sequence Number abgezogen werden, um die tatsächlich erhaltene Datenmenge zu bekommen (wobei sich dieses Ergebnis auch aus der Subtraktion von aktuellem Wert minus Start-Wert errechnen lässt). TCP-SYN/Synchronize Sequence Numbers Der Verbindungsaufbau von TCP arbeitet mit dem kleinen Schalter TCPSYN = Synchronize Sequence Numbers. Bei diesem logischen Handshake teilen sich die beiden TCP-Teilnehmer ihre Startwerte für die jeweilige Sequence Number mit. In der darauf folgenden Quittung (TCP-ACK) bestätigt jeder den Erhalt des Startwertes; so wird aus der Sequence Number des einen die Acknowledge Number des anderen. SEQ Number + Datenmenge + 1 = ACK Number Wird der Erhalt von Daten bestätigt, geschieht dies wie folgt: Nehmen wir an, der Sender hätte bei Offset 121000 eine Datenmenge von 512 Byte gesendet: Dann würde das TCP-Paket die Sequence Number »121000« tragen. >>> NEW TECH

Im Fokus des Analyzers: TCP

■

■

■

Hat der Empfänger das Paket fehlerfrei erhalten, quittiert er wie folgt: Er addiert zum Start-Offset die Datenmenge hinzu (121000+512=121512) und gibt dann mit »plus Eins« seinem Gegenüber den nächsten Start-Offset vor: 121512+1=121513. Der Datensender würde also das nächste TCP-Paket seinerseits ab Offset 121513 senden und als Sequence Number »121513« eintragen. Drängelei: Nun mach’ schon! Diese Regel kennt eine Abweichung: Wenn die Gegenstelle keine oder nur leere TCP-Pakete schickt, obwohl sie doch Daten zurückgeben soll, so wird nach einem Timer-Ablauf die Acknowledge Number (die somit zum StartOffset der Gegenstelle wird bzw. erst noch werden soll) ebenfalls um den Wert »1« hoch gezählt: Dies ist als Ausdruck deutlicher Ungeduld zu werten. Hilft auch das nichts, wird die Verbindung abgebrochen. Sendeaufforderung/Sendefreigabe Der Mechanismus ist also auch darauf ausgelegt, dass die Acknowledge Number nicht nur eine Empfangsbestätigung darstellt, sondern auch als Sendeaufforderung bzw. Sendefreigabe benutzt werden kann (in Abhängigkeit zur TCP Window Size). Durch die Verweigerung der Sendefreigabe kann sich ein TCP-Empfänger jederzeit wirkungsvoll vor Überlastung schützen. TCP Sliding Window Flow Control Um das Kernübel im Verhältnis von Sender und Empfänger, nämlich der Überlastung des Empfängers und einem einsetzenden Pufferüberlauf, wirkungsvoll entgegentreten zu können, entschied man sich bewusst gegen zwei bis dahin gängige Verfahren: TCP sollte kein Polling betreiben wir etwa SNA-Hosts. TCP sollte keine Ping-Pong-Dialoge führen. Bei Polling darf der eine nur senden, wenn der andere Daten abfordert; es gibt einen Master und einen Slave. Das taugt für Host-Terminal-Dialoge (SNA), aber nicht für Client-Server-Kommunikation und den beiderseitigen Austausch von Prozessdaten. Bei Ping-Pong ist das Verhältnis der Paketmenge zwischen Sender und Empfänger 1:1 – auf eine Datenanforderung kommt eine Datenrückgabe: Auf jedes Ping folgt ein Pong. Diese Variante wurde in den ersten LAN-Protokollen von Xerox verwendet und später von Novell in NCP-I übernommen (bevor der Burst Mode kam). Der extreme Nachteil dieser Ping-PongMethode ist, dass sie nur in LANs mit kurzen Paketlaufzeiten sinnvoll anwendbar ist; liegt zwischen den beiden Kommunikationsendpunkten (also zwischen den beiden TCP-Teilnehmern) ein ausgedehntes Weitverkehrsnetz (WAN), das zudem mit langsamen Leitungen arbeitet, würden sich nur für die Eins-zu-Eins gesendeten Quittungen so erhebliche Laufzeiten=Wartezeiten aufsummieren, dass die Arbeit für den Anwender völlig unerträglich wäre; jeder File Transfer würde bei größerer Datenmenge eine Ewigkeit dauern.

>>> NEW TECH

289

Kapitel 7 • TCP/IP-Grundlagen

■

■

■

290

Die Lösung bestand darin, dass mit jedem Ping (jeder Datenanforderung) zugleich die verfügbare Größe des Empfangsspeichers seitens dessen angegeben wird, der nach Daten verlangt. Die Gegenstelle, welche die Daten hat und zurückgibt, kann nun bis zum Erreichen dieser Speichermenge beliebig viele Pongs zurück geben: Die dem freien Empfangsspeicher entsprechende Datenmenge kann auf beliebig viele Pakete verteilt werden. Weiterhin muss seitens des Datengebers nicht auf Einzelquittungen gewartet werden – genau in diesem Effekt besteht der eigentliche Sinn des Verzichts auf das PingPong-Spiel: Statt immer nur mit Ping-Pong-Ping-Pong können die Daten nun mit Ping-Pong-Pong-Pong... gesendet werden. Diese Methode wird auch Burst Mode genannt. Eine Quittung vom anfordernden Empfänger ist erst nach Erhalt der freigegebenen Datenmenge notwendig – oder bei Ablauf des entsprechenden Timers. Die freigegebene Datenmenge wird Window genannt. Insofern aber bei TCP der Empfänger die freigegebene Datenmenge jederzeit frei ändern kann, wird das Verfahren Sliding Window Flow Control genannt. TCP Window Size Mit jeder Quittung, die der Empfänger schickt, gibt er eine neue freie Speichermenge bzw. Datenmenge an: Die Empfangs-Datenmenge des Anfordernden ist die Sende-Datenmenge des Rückgebenden. Somit kann jeder TCP-Teilnehmer die sog. TCP Window Size vom Grad seiner jeweiligen Speicherauslastung, aber auch von der Priorität des jeweiligen Prozesses abhängig machen – eine ideale Ausstattung für Inter Process Communication (IPC). Will ein TCP-Teilnehmer die Sendeleistung der Gegenstelle drosseln, verringert er von Quittung zu Quittung (TCP-ACK) den Wert der TCP Window Size. Soll die Gegenstelle gänzlich davon abgehalten werden, weiter zu senden (ohne aber die Session abzubrechen), wird die TCP Window Size vom Empfänger auf Null gesetzt. TCP Flags Um jedes Missverständnis auszuschließen, wird mit den TCP Flags nicht nur Verbindungsaufbau und -abbau signalisiert, sondern auch der Zweck eines jeden TCP-Paketes: Es wird angegeben, ob Daten enthalten sind (TCPPSH) oder der Empfang von Daten bestätigt wird (TCP-ACK). Three Way Handshake Der Verbindungsaufbau wird in drei Schritten getätigt: Wer eine Verbindung aufzubauen wünscht, sendet der Gegenstelle ein TCPSYN; die Gegenstelle antwortet mit TCP-SYN/ACK; der Initiator bestätigt dann noch einmal mit TCP-ACK. Somit wurden die Offsets (Sequence Numbers) ausgetauscht und beiderseitig bestätigt.

>>> NEW TECH

Im Fokus des Analyzers: TCP

Eine Übersicht hinsichtlich aller TCP-Paramter ist in Abschnitt 7.2.5 gegeben. Hier sei jedoch die Menge der TCP Flags wegen ihrer Bedeutung noch einmal vor Augen geführt: Abk.

Funktion

Bedeutung

URG

Urgent Pointer

Urgent Pointer am Ende des TCP Headers vorhanden (seltene Ausnahme).

ACK

Acknowledgement

Acknowledge Number lesen – dieses TCP-Paket enthält eine Quittung.

PSH

Push

Segment (Sequence) Requests A Push – es sind Daten vorhanden für den Destination Port.

RST

Reset

Reset Connection – das Verbindungsende wird angezeigt (bzw. bestätigt, wenn auch ACK gesetzt ist).

SYN

Synchronize

Synchronize Sequence Numbers – Verbindungsaufbau wird angezeigt (bzw. bestätigt, wenn auch ACK gesetzt ist).

FIN

Final

Final/End of Data Stream – Ende des Datenstroms wird angezeigt (bzw. bestätigt, wenn auch ACK gesetzt ist).

Tabelle 7.17: TCP Flags – Übersicht

Es soll ein TCP-Verbindungsaufbau gezeigt werden, weil er für den TCPMechanismus beispielhaft ist (Abbildung 7.23 ff.).

Abbildung 7.23: Verbindungsaufbau erst mit TCP, dann NetBIOS, dann SMB

Es ist ein typischer Verbindungsaufbau von Windows-Rechnern zu sehen: Der eigentliche Datendialog wird mit SMB (Server Message Block) auf Layer 7 abgewickelt; dem geht ein Session Request/Reply mit NetBIOS auf Layer 5 voraus; dem wiederum geht der TCP Handshake auf Layer 4 voraus. Der Initiator beginnt sein TCP-SYN mit dem Zufalls-Offset 45606, also der SEQ Number 45606, während ihm die ACK Number mit 0 noch unbekannt ist.

>>> NEW TECH

291

Kapitel 7 • TCP/IP-Grundlagen

Der Angerufene bestätigt den Verbindungsaufbau mit TCP-SYN/ACK, gibt die eigene SEQ Number mit 3090536426 an und bestätigt den Start-Offset des Initiators als ACK Number 45607. Dies wiederum bestätigt der Initiator mit TCP-ACK, SEQ Number 45607 und ACK Number 3090536427. Im Detail sieht das so aus:

Abbildung 7.24: Die IP-Adressen der beiden TCP-Teilnehmer beim Verbindungsaufbau

Abbildung 7.25: TCP-SYN (#2529) und TCP-SYN/ACK (#2530) beim Verbindungsaufbau

292

>>> NEW TECH

Im Fokus des Analyzers: TCP

Abbildung 7.26: TCP-SYN/ACK (#2530) und TCP-ACK (#2531) beim Verbindungsaufbau

Das Aushandeln von TCP-SYN, TCP-SYN/ACK sowie TCP-ACK hat also stattgefunden; auch die Offsets in Form von SEQ/ACK Numbers wurden bekannt gegeben und bestätigt. Gleichzeitig aber laufen noch zwei weitere Handshakes ab: Beide Teilnehmer teilen sich die Größe des jeweils freien Empfangsspeichers mit und handeln zudem noch die Maximum Segment Size aus, was dem kleinsten gemeinsamen Nenner bzgl. der Physical Frame Size bzw. Maximum Transmission Unit entspricht, bezogen auf die jeweiligen IP Subnets (ggf. LANs), in denen die beiden Teilnehmer residieren. Im Folgenden werden die TCP-Parameter und die damit verbundenen Fehler und Auffälligkeiten dargelegt; danach folgt ein Abschnitt, der sich mit automatischer Auswertung beschäftigt.

>>> NEW TECH

293

Kapitel 7 • TCP/IP-Grundlagen

Abbildung 7.27: TCP Handshake mit Window Size & Maximum Segment Size

7.8.2

TCP: Source/Destination Port

Fehler mit den TCP-Ports sind Raritäten; es dürfte kaum vorkommen, dass eine TCP-Absender eine defekte Port-Kennung verwendet.

Abbildung 7.28: TCP Header mit Source & Destination Port, Sequence & Acknowledge Number und Data Offset

294

>>> NEW TECH

Im Fokus des Analyzers: TCP

TCP: Einheitliche Sockets Die UDP/TCP-Ports sind bis zum Dezimal-Wert von 1.024 weltweit einheitlich, wobei die Ports bis 512 die sog. BSD Sockets (oder: Well-Known Sockets) und die darüber bis 1.024 liegenden Port die weiteren, für Unix typischen Sockets sind. Socket

Protocol

0000-0001

(reserviert)

0005

RJE – Remote Job Entry

0007

ECHO – Echo

0011

USERS Active Users

0013

DAYTIME – Daytime

0017

QUOTE - Quote of the Day

0019

CHARGEN – Character Generator

0021

FTP – File Transfer Protocol

0023

TELNET – Teletype Network

0025

SMTP – Simple Mail Transfer Protocol

0037

TIME – Time

0039

RLP – Resource Location Protocol

0041

GRAPHICS – Graphics

0042

NAMESERVER – Host Name Server

0043

NICNAME – Who Is

0053

DOMAIN – Domain Name Server

0067

BOOTPS – Bootstrap Protocol Server

0068

BOOTPC – Bootstrap Protocol Client

0069

TFTP – Trivial File Transfer Protocol

0079

FINGER – Finger

0107

RTELNET – Remote Telnet Service

0109

POP-2 – Post Office Protocol, Version 2

0111

SunRPC – SUN Remote Procedure Call Port Map

0113

AUTH – Authentication Service

0115

SFTP – Simple Mail File Transfer Protocol

0119

NNTP – Network News Transfer Protocol

0123

NTP – Network Time Protocol

0137

NETBIOS-NS – NETBIOS Name Service

0138

NETBIOS-DGM – NETBIOS Datagram Service

Tabelle 7.18: Auswahl gängiger UDP/TCP-Ports

>>> NEW TECH

295

Kapitel 7 • TCP/IP-Grundlagen

Socket

Protocol

0139

NETBIOS-SSN – NETBIOS Session Service

0161

SNMP – Simple Network Management Protocol/Get & Response

0162

SNMP – Simple Network Management Protocol/Trap

0512

REXEC – Remote Exec

0513

RLOGIN – Remote Login

0514

REMSHELL – Remote Shell

0515

LPR – Remote Print

0900

Unix printer

Tabelle 7.18: Auswahl gängiger UDP/TCP-Ports (Forts.)

Eine Abweichung von den bekannten bzw. festgesetzten Sockets bzw. Ports verhindert den Verbindungsaufbau; daher ist von einer Änderung in den PortKennungen allgemein abzuraten. PMAP: Port Mapper Protocol Sind für einen bestimmten Service die Sockets unklar, kann ein IP-Teilnehmer versuchen, den Socket mit dem sog. Port Mapper Protocol (PMAP) in Erfahrung zu bringen. TCP: Config-Dateien Es ist hier auf eine bei Unix seit alters her verwendete Config-Datei zu verweisen: /etc/services

Bei Microsoft-Rechnern kann umgekehrt eingestellt werden, dass sie nicht auf alle Socket-Calls antworten sollen; es können also bestimmte Sockets ausgeklammert werden. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ EnableSecurityFilters HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\TcpAllowedPorts HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\UdpAllowedPorts

Es kann aber auch schon sein, dass ein TCP-Rechner nicht antworten kann, weil er das Maximum an TCP-Verbindungen erreicht hat, das er unterstützen kann. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ TcpNumConnections

296

>>> NEW TECH

Im Fokus des Analyzers: TCP

Wenn ein IP-Teilnehmer auf einen UDP/TCP-Call nicht antworten kann, weil der UDP/TCP-Socket nicht aktiv ist (weil der entsprechende Prozess darüber nicht gestartet ist), so wird eine entsprechende Meldung an den Rufenden gesendet: »ICMP: Destination Unreachable/Service Unavailable« Siehe hierzu: Abschnitt 7.6.1.

Abbildung 7.29: ICMP »Destination unreachable/Port unavailable«

Anders sieht es aus, wenn nicht der Gerufene einen Port nicht unterstützt, sondern wenn schon der Rufende keinen neuen Socket eröffnen kann. Seitens des Windows-Clients kann die Begrenzung greifen, dass nicht genügend viele Sockets bzw. Ports eröffnet werden können bzw. dürfen; auch hierzu gibt es eine Registry-Einstellung. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ MaxUserPort

Ein Socket, der geschlossen wurde, darf nicht sofort wieder neu verwendet werden; er muss für eine Mindestzeit geschlossen bleiben, was bei einer raschen Folge von Öffnen-Schließen bei Sockets eine gewissen Einengung bedeuten kann. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ TcpTimedWaitDelay

Bestehende Sockets bzw. die darüber laufenden TCP-Sessions müssen ggf. gepflegt werden, indem sich die TCP-Partner gegenseitig versichern, noch da zu sein und die Session auch aufrecht erhalten zu wollen.

>>> NEW TECH

297

Kapitel 7 • TCP/IP-Grundlagen

WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ KeepAliveInterval HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ KeepAliveTime

Will ein TCP-Rechner zu einem anderen eine Verbindung aufbauen, der aber will nicht, so könnte der Anrufer seine Versuche im Extremfall endlos wiederholen; dies aber unterbinden die TCP-Treiber. Die Zahl der TCP-SYN-Versuche ist also begrenzt, ebenso wie die Zahl der Antworten darauf mit TCP-SYN/ ACK. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ TcpMaxConnectResponseRetransmissions HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ TcpMaxConnectRetransmissions

7.8.3

TCP: Sequence/Acknowledge Number

TCP-Analyse hat hauptsächlich mit der Auswertung der Offset-Kennungen zu tun, die hier Sequence Number und Acknowledge Number heißen, sowie der Window Size – diese drei Parameter machen größtenteils die Inhalte der Data Flow Control aus (neben den Befehlen in den TCP Flags). Siehe hierzu die Darlegungen in Abschnitt 7.8.1. Die SEQ/ACK Numbers sind bei manueller Durchsicht der Daten im Analyzer bzw. Decoder herzlich uninteressant – sofern es nicht eine Fundstelle gibt, in der eine Störung sichtbar wird. Es ist aber völlig abwegig, Hunderte und Tausende von Paketen auf solche Auffälligkeiten hin durchzusehen. Das überlässt man heute den Expertensystemen. Auffälligkeiten im Datenfluss werden hier gut erkannt. Beispiel: Fehler in der Offset-Folge Das folgende Beispiel stammt aus Ende 1999 und zeigt einen WinNT-PDC (Primary Domain Controller), der defekte TCP-Sendefolgen erzeugt. Aus der Sicht des Anwenders würde das wieder bedeuten: »Das Netzwerk ist langsam.« Tatsächlich aber springt der WinNT-Server ständig in seinen Übertragungen zurück wie eine alte Langspielplatte mit Sprung. In Abbildung 7.30 ist eine solche automatische Auswertung zu sehen:

298

>>> NEW TECH

Im Fokus des Analyzers: TCP

Abbildung 7.30: TCP Expertendiagnose (LANdecoder32)

1. Das obere Fensterdrittel zeigt eine Liste aller TCP-Sessions, wobei hier bereits Auffälligkeiten aufgelistet werden. 2. Das mittlere Fensterdrittel listet alle TCP-Pakete der Verbindung auf samt Zusammenfassung der wichtigsten Merkmale (SEQ/ACK Number, Window Size) und Fehler (z.B. Small Packet, Retransmitted Packet). 3. Das untere Fensterdrittel zeigt eine Zusammenfassung der wichtigsten Verbindungsdaten an, darunter die Zahl der wiederholten Pakete und Bytes sowie die Dauer der Verbindung und die Gesamtdatenmenge. Jetzt könnte nach der Ursache der Wiederholungen gesucht werden, indem mit dem Mauszeiger auf die Zeile geklickt wird, die den Hinweis auf das wiederholte Paket gibt. Ein Beispiel, in dem sich das offenkundig anbietet, ist in Abbildung 7.31 zu sehen. In Abbildung 7.31 wird sichtbar, dass sehr viele TCP-ReTx (Retransmissions) erkannt wurden. In Abbildung 7.32 wird das Geschehen sichtbar: Der Sender mit IP=192.168.254.100 fällt ohne jeden ersichtlichen Grund auf einen vorherigen, bereits zurückliegenden Offset zurück.

>>> NEW TECH

299

Kapitel 7 • TCP/IP-Grundlagen

Abbildung 7.31: TCP Retransmitted Packets – viele Wiederholungen

Abbildung 7.32: TCP-Fehler (1): Rücksprung in der Sequence Number (#2268, #2269)

300

>>> NEW TECH

Im Fokus des Analyzers: TCP

Die Tabelle 7.19 fasst das Ereignis zusammen: Paket

IP Sender

Aktion

Offset

Kommentar

#2266

192.168.254.100

sendet

#2267

10.23.19.5

quittiert

ab

SEQ=3.447.537

=1.460 Byte

bis

ACK=3.448.997

Bestätigung bis Offset 3.448.996

#2268

192.168.254.100

#2269

192.168.254.100

sendet

ab

SEQ=3.448.997

sendet

ab

SEQ=3.441.697

Rücksprung um -7.300 Byte

#2271

10.23.19.5

quittiert

bis

ACK=3.450.457

= 3.448.997 + 1.460

Tabelle 7.19: Ablauf von Sequence Number/Acknowledge Number (1)

Die TCP-ReTx in Paket 2.269 (und damit der Rücksprung auf einen früheren Offset) erscheint völlig unsinnig, zumal die Wiederholung in derselben Zehntausendstel-Sekunde erfolgt wie das vorige Paket 2.268. Es stellt sich die Frage: Tut das IP=192.168.254.100 das von sich aus, oder wird der Rechner von außen dazu veranlasst? Da im Vorlauf IP=10.23.19.5 völlig korrekt quittiert hat, ist die TCP-ReTx unsoliticed, heißt: ohne eigentlichen Anlass. Man könnte das auch einen unforced error nennen. Dieser Befund wird dadurch gestützt, dass nur kurze Zeit später der Host an derselben Stelle wieder festhängt und erneut zurückspringt.

Abbildung 7.33: TCP-Fehler (2): mehrfache Rücksprünge und Retransmissions

Mit Paket 2292 wird die alte, bereits schon früher einmal erreichte Stelle mit Offset bzw. SEQ=3.448.997 erneut erreicht, und sodann wird in Paket 2295 zurück gesprungen auf Offset bzw. SEQ=3.446.077. >>> NEW TECH

301

Kapitel 7 • TCP/IP-Grundlagen

Die Tabelle 7.19 fasst das Ereignis zusammen: Paket

IP Sender

Aktion

Offset

Kommentar

#2278

192.168.254.100

sendet

ab

SEQ=3.443.157

#2279

192.168.254.100

sendet

ab

SEQ=3.444.617

#2281

10.23.19.5

quittiert

bis

ACK=3.450.457

wie #2271 Quittung für #2268

#2283

10.23.19.5

quittiert

bis

ACK=3.450.457

wie #2271 Quittung für #2268

#2289

192.168.254.100

sendet

ab

SEQ=3.446.077

#2290

192.168.254.100

sendet

ab

SEQ=3.447.537

#2291

10.23.19.5

quittiert

bis

ACK=3.450.457

#2292

192.168.254.100

sendet

ab

SEQ=3.448.997

#2293

10.23.19.5

quittiert

bis

ACK=3.450.457

wie #2271 Quittung für #2268

#2294

10.23.19.5

quittiert

bis

ACK=3.450.457

wie #2271 Quittung für #2268

#2295

192.168.254.100

sendet

ab

SEQ=3.446.077

Rückschritt um 2.990 Bytes

wie #2271 Quittung für # 2268

Tabelle 7.20: Ablauf von Sequence Number/Acknowledge Number (2)

Es wird im Beispiel offenkundig, dass die Wiederholungen bzw. Rücksprünge nicht durch fehlende oder zu spät erfolgende Quittungen der Gegenstelle entstehen – die TCP-ACKs kommen sämtlich prompt und vollzählig. Tatsächlich liegt hier ein schwerer Fehler beim Absender vor. Ob die Ursache nun im TCP-Treiber, der Applikation und/oder einem weiteren Faktor zu suchen ist, kann allerdings aus den Messdaten nicht mehr entschlüsselt werden. TCP: Das Ereignis der ReTx (Retransmissions) Es sollte klar geworden sein, wie TCP-ReTx aussehen und wie sie erkannt werden können. Hier nun muss weiterhin beachtet bzw. erinnert werden: Es wurde weiter oben über die eindeutigen IP-Paket-Nummern gesprochen: Die IP Fragment IDs geben keinen Aufschluss über etwaige Wiederholungen. Denn die Wiederholung betrifft allein den TCP-Teil sowie die nachfolgenden Daten;

302

>>> NEW TECH

Im Fokus des Analyzers: TCP

der IP-Header aber bleibt davon in jedem Falle unberührt, was heißt: Er wird für jedes TCP-Paket neu gebildet, und sei es auch eine TCP-ReTx. TCP-Wiederholungen werden nur erkannt am Daten-Offset-Zähler, der Sequence Number (SEQ No.); springt diese zurück oder verharrt sie über mehreren Paketen, obwohl Nutzdaten gesendet werden, so ist klar, dass es sich um Wiederholungen handelt. Wiederholungen können folgende Gründe haben: ■ ■

■ ■

IP-Pakete des Absenders gehen auf dem Weg zum Empfänger verloren. Der Empfänger leidet an Pufferüberlauf und verwirft die Pakete. Dann sollte er übrigens mit »ICMP: Source Quench« eine Staumeldung zurück geben (siehe 7.6.6). Der Applikationsprozess oder der entsprechende Protokolltreiber sind fehlerhaft und nicht in der Lage, die Quittung zu generieren. Die Quittung des Empfängers geht auf dem Weg zum Partner verloren.

Um darüber Aufschluss zu erlangen, welche dieser Ursachen vorliegt, muss ggf. eine sog. Drei-Punkt-Messung vorgenommen werden: Ein Analyzer steht unmittelbar neben dem Server, ein zweiter mitten im Backbone, ein dritter unmittelbar neben dem Client-PC. TCP: Paketverlust und die Folgen Gingen tatsächlich auf der Leitung Pakete verloren, so reagiert der Empfänger wie folgt: Er quittiert genau den Offset, bis zu dem er ■ ■

lückenlos und fehlerfrei

Daten erhalten hat; dies gilt auch (und gerade!), wenn er bereits Daten höherer Offsets erhalten hat, zu diesen aber wegen eines fehlenden TCP-Pakets noch keine geschlossene Datenreihe hat. Der Absender wird daraufhin die fehlende Datenmenge erneut senden, da er ja nur die Quittung bis zu einem früheren Offset-Wert erhielt. Kaum füllt sich beim Empfänger damit das fehlende Glied in der Datenkette, quittiert er nicht etwa nur die just erhaltene Nachsendung, sondern wieder die gesamte Datenmenge, die er nunmehr lückenlos und fehlerfrei erhalten hat – was einen großen Offset-Sprung nach vorne in der TCP ACK Number bedeuten kann. Trifft dieses neue TCP-ACK beim Sender rechtzeitig ein, kann er sich das Verschicken weiterer Nachsendungen ersparen – war er doch bis dahin davon ausgegangen (zwangsweise), dass alle Daten ab dem letzten TCP-ACK verloren gegangen wären. Nun erkennt also der Sender, dass offenkundig nur eine Teilmenge verloren gegangen war, und setzt seine Übertragungen an dem Offset fort, an dem er auch ursprünglich verharrt hatte.

>>> NEW TECH

303

Kapitel 7 • TCP/IP-Grundlagen

Trifft also beim Absender keine Quittung bis zum letzten, erreichten Offset ein, sondern nur für einen älteren, kleineren Offset-Wert, so wird ab dem letzten bestätigten Offset erneut mit der Übertragung begonnen. Optimal läuft das Szenario, wenn der Empfänger seine Teilquittung, die als Nachforderung zu verstehen ist, mit einer TCP Window Size versieht, die exakt der fehlenden Datenmenge entspricht. TCP: Die Häufigkeit der Wiederholungen Müssen per TCP-ReTx Pakete wiederholt gesendet werden, stellen sich Fragen: ■ ■ ■

Nach welcher Wartezeit auf TCP-ACK wird die TCP-ReTx ausgelöst? Und wie oft wird eine TCP-ReTx ausgeführt, wenn es dann immer noch keine TCP-ACKs als Quittung gibt? Wann wird die TCP-Session aufgegeben?

Die Fragen sind wie folgt zu beantworten: ■

■ ■ ■ ■

TCP ermittelt während der laufenden TCP-Session die mittlere Wartezeit, die verstreicht, bis auf ein eigenes TCP-Paket die Antwort der Gegenstelle kommt. Verstreicht die doppelte Zeit (also das Zweifache der mittleren Wartezeit), wird die TCP-Wiederholung ausgelöst. Mit jeder Wiederholung wird die Wartezeit verdoppelt. Der Vorgabewert für die Gesamtzahl der Wiederholungen liegt bei 5. Ist nach fünf Wiederholungen kein TCP-ACK der Gegenstelle eingetroffen, wird die Verbindung mit TCP-FIN und TCP-RST beendet. (Allerdings ist dann fraglich, ob diese Schlussmeldungen von der Gegenstelle überhaupt noch empfangen werden.)

Die maximale Zahl der TCP-Wiederholungen kann in der WinNT Registry eingestellt werden; dies ist auf WAN-Leitungen oder chronisch überlasteten Clients und/oder Servern durchaus zu empfehlen. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ TcpMaxDataRetransmissions

7.8.4

TCP: Data Offset

Dies ist eine einfache Längenangabe, die indirekt besagt, welche Länge der TCPHeader hat. Bei IP heißt das IP Header Length. Hier eben bezeichnet der TCP Data Offset, wie viele Bytes hinter dem Beginn des TCP-Headers die Nutzdaten liegen. Doch auch mit dieser simplen Angabe kann es im Argen liegen, wenn sie falsch gesetzt wird.

304

>>> NEW TECH

Im Fokus des Analyzers: TCP

Beispiel: Der Offset-Wert stimmt nicht Das folgende Beispiel zeigt, wie massiv sich hier Fehler auswirken können.

Abbildung 7.34: X-Window – scheinbar jedenfalls

Es fiel auf, dass eine IP-Station angeblich X-Window-Pakete schickte, obwohl dies bislang nicht bekannt war. Bei näherem Hinsehen stellte sich heraus, dass es sich nicht um X-Window handeln kann: Wie der sog. Hex-Dump zeigt (das Fenster unten links in Abbildung 7.34), taucht die Textfolge select int_val from... dort auf, wo nach der X-Window-Regel Fensterkoordinaten etc. sein sollten. Das konnte also nicht sein. Ein Blick in den TCP-Header zeigte: Der Fehler lag in einem falsch formatierten Wert für TCP Data Offset. Schon der Umstand, dass der TCP-Header in einer laufenden Session sog. TCP Options verwenden sollte (das kommt sonst nicht vor), weist auf Fehler hin. Und schon gar nicht kann es sein, dass auf die Angabe No Options dieselbe noch einmal kommt und sodann eine TimeStamp Option. Was war falsch? Der Wert für TCP Data Offset betrug nicht (dezimal ausgerechnet) 20, sondern 32 – mit der Folge, dass 12 Byte als Verlängerung des TCP-Headers gerechnet wurden, die doch tatsächlich bereits zum nächsten Protokoll gehörten. Auch das sonst wirkungsvolle Expertensystem des Analyzers (LANdecoder32) hatte diesen TCP-Fehler nicht erkannt – die Programmierer waren offenbar nicht auf die Idee gekommen, dass ein TCP-Treiber diesen Wert falsch setzen könnte.

>>> NEW TECH

305

Kapitel 7 • TCP/IP-Grundlagen

Abbildung 7.35: TCP-Fehler: Der Längenwert in »Data Offset« stimmt nicht

Dies ist ein schöner Beweis für die Tatsache, dass man um die Handarbeit letzten Endes nur bei wirklich simplen Fehlern herumkommt.

7.8.5

TCP: Flags

Auf den ersten Blick sieht es nicht so aus, als könnte mit diesen sechs Bits etwas Auffälliges vor sich gehen. Aber das scheint nur so. Zur Diskussion der TCP Flags sei auf Tabelle 7.17 verwiesen. Fehler: Leere Pakete mit TCP-PSH Flag Ein Kunde berichtete, dass in Abständen die AS/400 abstürzen würde. Immer einige Zeit davor würden sich Telnet-Terminals mit weißem Bildschirm aufhängen. Es stellte sich in der Tat heraus, dass die AS/400 defekt war. Immer ab einer längeren Betriebsdauer begann sie, nach und nach mehr Fehler in ihrer TCP/IPKommunikation zu machen. Ein Fehler bestand darin, leere TCP-Pakete zu verschicken, in denen trotz des Umstandes, dass sie leer waren, das TCP Push Flag gesetzt war. Dieser Steuerbefehl aber besagt, dass im TCP-Paket transportierte Daten an den TCP Destination Port ausgeliefert werden sollten.

306

>>> NEW TECH

Im Fokus des Analyzers: TCP

Abbildung 7.36: TCP Header mit Flags: FIN, SYN, RST, PSH, ACK, URG

Zu dem Fehler der AS/400 kam dann der zweite Fehler, dass die TCP- und Telnet-Treiber der Terminals das tatsächlich versuchten, anstatt die Pakete zu verwerfen. Immerhin ergab sich aus dem Wert IP Total Length = 40 eindeutig, dass wirklich keine Daten enthalten waren. Der Zufall aber wollte es, dass die Programmierer der TCP/IP-Treiber diesen Fall offenkundig nicht vorhergesehen hatten und dem TCP Push Flag unbedingte Ausführung einräumten. Und wo keine Daten waren, füllte sich der Bildschirm eben ganz oder teilweise weiß.

Abbildung 7.37: TCP-Fehler: Push Flag bei leerem Paket

>>> NEW TECH

307

Kapitel 7 • TCP/IP-Grundlagen

Aber das war – bei besagtem Kunden – dann auch schon egal, weil die AS/400 dann sowieso immer bald ihren Geist aufgab und neu gestartet werden musste. Ein Austausch der Treiber konnte Abhilfe schaffen. In Abbildung 7.37 ist ein solches Paket der AS/400 zu sehen: Die IP Total Length zeigt 40 an (20 Byte für den IP-Header, 20 Byte für den TCP-Header), und dennoch ist das TCP Push Flag gesetzt. Es sei auf Abschnitt 7.7.3 verwiesen. Fehler: TCP-SYN Flooding Sei es aufgrund eines Fehlers, sei es aufgrund von Hackerangriffen – es kann geschehen, dass eine Maschine mit TCP-SYN-Paketen überflutet wird. Alte WinNT Maschinen (vor Version 4) konnten bei solchen Ereignissen abstürzen. Microsoft hat daraus in zweierlei Weise die Konsequenz gezogen: ■ ■

Vor die Internet-Domain www.microsoft.com wurde eine Firewall gestellt, und die Webserver laufen jetzt angeblich auf Sun-Solaris Maschinen. Die WinNT-Registry kennt jetzt einen Eintrag, der WinNT-Server gegen TCP-SYN-Fluten unempfindlich machen soll.

Der Registry-Eintrag TcpMaxConnectResponseRetransmissions wurde mit WinNT Version 4, Service Pack 2 eingeführt. Auf wiederholte TCP-SYN-Rufe wird mit Pausen geantwortet, die per Voreinstellung wie folgt gestaffelt sind: drei, sechs und zwölf Sekunden; danach wird für weitere 24 Sekunden gewartet. Insgesamt beträgt der Zyklus also 45 Sekunden. Der zweite Registry-Eintrag TcpMaxConnectRetransmissions soll schon auf der Seite des TCP-SYN-Rufers die Zahl der Versuche begrenzen; allerdings ist dieser Parameter nicht per Vorgabe gesetzt. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ TcpMaxConnectRetransmissions HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ TcpMaxConnectResponseRetransmissions

Fehler: TCP-SYN wird mit TCP-RST beantwortet Aber auch ohne den o.g. Registry-Eintrag muss damit gerechnet werden, dass TCP-Rechner im Falle einer Überlastung auf neue TCP-SYN-Anrufe mit TCPRST antworten. In diesem Falle geben sie zu verstehen, dass es der Anrufer später noch einmal neu versuchen soll. Teilweise kann diese Reaktion allerdings auch durch Firewall-Systeme verursacht werden, die gemäß ihrer Konfiguration einen TCP-SYN-Versuch mit den gegebenen TCP-Sockets nicht zulassen dürfen.

308

>>> NEW TECH

Im Fokus des Analyzers: TCP

Hier streiten sich die Gelehrten, ob eine solche TCP-RST-Rückgabe korrekt und gut sei, oder ob es nicht besser sei für eine Firewall, schlicht gar nichts zu antworten. Fehler: Ausstehende TCP-ACKs Zu einer Standardkrankheit gehört, dass TCP-Pakete nicht schnell genug gegenüber dem Absender quittiert werden. Dies ist allgemein die Folge einer Überlastung von Endgeräten oder Servern. Wo immer das beobachtet wird, muss über eine Aufrüstung oder Konfigurationsänderung der betroffenen Maschinen nachgedacht werden. Dies spricht nicht gegen ein Abwarten seitens der Empfängers, bis die mit TCP Window Size gegenüber dem Absender annoncierte Speichermenge im Eingangspuffer gefüllt ist. Der Fehler ist, dass dieser Mechanismus unterlaufen wird; siehe Abschnitt 7.8.6. Fehler: TCP-FIN und TCP-RST werden nicht beantwortet Es gehört zu den allgemeinen Erscheinungen von Internet Webservern, auf TCP-FIN und TCP-RST seitens der WebClients nicht zu antworten. Vermutlich fühlen sich die hohen Herren der Webserver-Zunft von solchen Nebensächlichkeiten belästigt. Jeder kann den Beweis antreten: Messen Sie einmal eine normale InternetSession mit HTTP/HTML-Zugriffen – und Sie werden diese Erscheinung massenhaft wahrnehmen können. Die Folge ist: ■ ■ ■ ■

■

Im Internetbrowser (Mircosoft, Netscape etc.) zeigt ein kleiner Laufbalken an, dass angeblich immer noch auf Daten aus dem Internet gewartet werde. Der Anwender fragt sich: Wieso? Die ganze Seite ist doch schon da? Und, falls der Anwender nicht auf den Button »Abbrechen/Stop« drückt: Erst nach Ablauf des entsprechenden TCP-Timers beendet der Browser die Warterei auf die ausstehenden Meldungen TCP-FIN/ACK und TCP-RST/ ACK; erst jetzt wird der Zugriff als beendet eingestuft. Im schlechtesten Fall wird erst jetzt die HTML-Seite im Browser aufgebaut.

Und – was sagt der Anwender dazu? Richtig: »Das Netzwerk ist zu langsam.« Oder, mal in einer Variante: »WWW = World Wide Waiting. Bestimmt ist das Internet überlastet.« Ach, ja ...

>>> NEW TECH

309

Kapitel 7 • TCP/IP-Grundlagen

Fehler: Die TCP KeepAlive-Meldungen kommen zu oft oder zu spät TCP-ACKs werden durch einen TCP-Treiber auch gesendet, um bei Verbindungen, die lange keine Daten übertragen, sicherzustellen, dass die Gegenstelle noch präsent ist und die Verbindung auch weiter aufrecht erhalten möchte – bzw. um ihr mitzuteilen, dass sie dies selber möchte. Es kann zu Fehlern kommen, wenn die KeepAlive-Timer nicht identisch gesetzt sind. Zwar sollte dann der Ablauf so sein, dass der eine zuerst TCP-ACKs als Meldung des Session Alive sendet, und dass der andere dann antwortet – und doch wohnt in verschiedenen Timern potenziell das Fehlerteufelchen. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ KeepAliveInterval HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ KeepAliveTime

7.8.6

TCP: Window Size

Kein Parameter von TCP wird permanent so falsch behandelt wie dieser – und dabei stellt er doch das zentrale Element der TCP Data Flow Control dar, indem es die TCP Sliding Window Flow Control ermöglicht.

Abbildung 7.38: TCP-Header mit Window Size & Checksum

Zur Erinnerung (siehe 7.8.1): Jeder TCP-Teilnehmer gibt seiner Gegenstelle mit diesem Wert bekannt, welche Speichermenge für eingehende Daten eben dieser Gegenstelle reserviert sind, und die Gegenstelle hat damit die Freigabe, die entsprechende Datenmenge zu senden (ungeachtet der Zahl der Pakete, auf die sich das verteilt), ohne einzeln Quittungen des Empfängers abwarten zu müssen. Der Empfänger schickt im besten Fall bei Eintreffen der vollen Datenmenge eine einzige Quittung über die Gesamtmenge, die erhalten wurde.

310

>>> NEW TECH

Im Fokus des Analyzers: TCP

Bei WinNT-Maschinen ist die maximale TCP Window Size per Vorgabe auf 65.535 Bytes gestellt – mehr geht nicht. Sollte die Vergabe der Puffergrößen zwischen den verschiedenen Applikationen unbefriedigend sein, könnte über eine zwangsweise Einengung nachgedacht werden. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ TcpWindowSize

Fehler: TCP Window Size fällt auf Null Wenn die TCP Window Size auf Null fällt, ... ■

■

kann das normal sein – wenn nämlich der Empfang eines Paketes schon mal mit TCP-ACK bestätigt wird, ohne sofort gleichzeitig eine neuerliche Freigabe zu erteilen; kann das ein Zeichen für Fehler sein (Pufferüberlauf, Treiberfehler).

Fällt ein solches Ereignis einmal auf, muss unbedingt geprüft werden, ob sich dieses wiederholt, und – falls ja – ob diese Ereignisse von bestimmten Bedingungen abhängig sind. Gleiches gilt für das nächste Symptom. Fehler: TCP Window Size ist sehr klein, aber nicht Null Wenn ein TCP-Treiber mit sehr kleinen Werten für die TCP Window Size arbeitet, ■ ■

kann das kurzfristig eine Reaktion auf Speichermangel sein; ist dies aber ein Zeichen für einen (vermutlich schweren) Fehler, wenn dies dauerhaft oder in starken Wiederholungen auftritt.

Bei großen Datenmengen, die es zu übermitteln gibt, hat es schlicht keinen Sinn, wenn der Empfänger mal für 7 Bytes, mal für 21 Bytes die Übertragung erneut freigibt. Bei Datenbankzugriffen kann daraus sogar folgen, dass Datensätze nicht mehr übertragen werden können. In jedem Fall wird die Übertragung z.B. einer Datei durch kleine TCP Window Sizes sehr, sehr langsam. Dann heißt es wieder: »Das Netzwerk ist zu langsam.« Fehler: TCP Window Size ist eingefroren Es kann vorkommen, dass über mehrere Pakete hinweg die TCP Window Size seitens eines TCP-Teilnehmers nicht geändert wird. Dies kann tatsächlich regulär vorkommen, ist aber sehr selten. Wird dies entdeckt, gilt dies als Frozen Window und wird als (möglicher) Fehler angesehen; vermutet wird, dass die Gegenstelle zwar noch senden, aber keine sinnvollen Protokolloperationen mehr durchführen kann.

>>> NEW TECH

311

Kapitel 7 • TCP/IP-Grundlagen

Fehler: Die TCP Window Size wird nicht genutzt Anders ist es, wenn nicht der Empfänger seine eigene TCP Window Size unterläuft, wie in Beispiel (1) gezeigt, sondern wenn der Sender von TCP-Daten die TCP Window Size der Gegenstelle (also des Empfängers) ignoriert. Das Szenario zeichnet sich im schlechtesten Falle durch folgende Elemente aus: ■ ■

■ ■

■ ■

■

Ein Server erhält Datenanforderungen von einem Client, der zudem eine große TCP Window Size bekannt gibt. Der Server sendet nicht etwa Daten in der frei gegebenen Menge (das wäre: Sendemenge = TCP Window Size des Empfängers), sondern immer nur kleine Mengen. Dies wäre bei Datenbankzugriffen vertretbar, wenn die Datensätze nur klein sind. Aber bei Dateizugriffen bzw. Dateiübertragungen ist das NichtAusschöpfen der freigegebenen TCP Window Size ein schwerer Fehler. Der Server wartet nunmehr auf das TCP-ACK des Clients. Der Client seinerseits wartet auf weitere Daten, weil er glaubt, der Server werde die freigegebene Puffergröße ausschöpfen. Erst nach Ablauf des entsprechenden TCP-Timers sendet der Client das fällige TCP-ACK. Erst jetzt sendet der Server weitere Daten. Die Folge ist, dass es viel mehr TCP-ACKs gibt, als nötig wäre; zu den immensen Wartezeiten beim Client (der auf weitere Daten wartet), kommen die erheblichen Paketlaufzeiten über langsame WAN-Leitungen. Im Effekt heißt es wieder bei den Anwendern: »Das Netzwerk ist zu langsam.«

Es muss leider festgestellt werden, dass das beschriebene Fehlverhalten bei Unix-Rechnern eindeutig selten, bei Windows-Rechnern (so oder so ähnlich) aber eindeutig die Regel ist. Fehler: TCP-ACKs, die keine sind (aber dafür stören) Oft können insbesondere Windows-Rechner dabei beobachtet werden, wie sie trotz der bekannt gegebenen TCP Window Size laufend TCP-ACKs senden (was absolut unsinnig und oft auch hinderlich ist), ■ ■

obwohl die angegebene Speichermenge noch gar nicht erhalten wurde, obwohl auch keine Timer abgelaufen waren, die kein weiteres Abwarten mehr zulassen würden;

wobei die laufend gesendeten TCP-ACKs aber widersinnig sind, weil sie nicht etwa die tatsächlich erhaltenen Daten quittieren, sondern ältere, schon lange zurückliegende Offsets. Man hätte ja Verständnis dafür, dass Rechner langsam oder überlastet wären; aber ■

312

praktisch auf jedes eingehende Paket ein TCP-ACK zu senden;

>>> NEW TECH

Im Fokus des Analyzers: TCP

und das nicht auf den aktuellen Offset des Senders, sondern auf irgendeinen alten Offset; ■ und dann so, dass viele, viele TCP-ACKs mit demselben, alten Offset-Wert in der ACK-Number geschickt werden (!!); das ist das Maximum an Sinnlosigkeit. ■

Es ist sehr schwer zu erkennen, ob und wann hierfür der TCP-Treiber verantwortlich ist, die Applikation und/oder andere Faktoren. Insbesondere auf WAN-Leitungen macht sich dieses Verhalten sehr störend bemerkbar. Aber auch in LANs hat dieses Verhalten, sofern es von vielen Clients gezeigt wird, die Folge, dass die Server in sehr hoher Zahl mit TCP-ACKs belastet werden, die es nach reiner TCP-Lehre gar nicht geben dürfte. Fehler: Windows Terminal Server (WTS/TSE) Seit zwei Jahren (zuletzt Ende 1999) konnte der Autor bei verschiedenen Kunden beobachten, wie große Projekte (Wert: bis zu 7-stelligen Millionen-Beträgen) scheiterten, weil Windows Terminal Server (WTS) der Microsoft Terminal Server Edition (TSE) bzw. die Terminal-Clients nicht in der Lage waren/sind, die TCP Sliding Window Flow Control korrekt zu nutzen. Waren doch die Terminalkonzepte dazu gedacht, alte Hardware weiter verwenden zu können, indem die Applikationen auf WinNT-Servern laufen, die wiederum nur die Video-Daten an die Clients ausgeben! Insbesondere ein großer, namhafter Hersteller einer auf MS-TSE basierenden WTS-Lösung war bei vielen sehr großen Unternehmungen der Bundesrepublik Deutschland außerstande, die Projekte zum Laufen zu bringen – und das unter der Bedingung, dass es woanders sehr wohl läuft bzw. lief. Hier zeigt sich eine Schwachstelle des WinNT-Konzepts: Jede Applikation eines WinNT-Servers, die über die LAN/WAN-Protokolle arbeitet, kann diese zur Laufzeit mit eigenen Parametern einstellen – und sie dazu bringen, z.B. im Einzelquittungsbetrieb zu arbeiten, also wieder Ping-Pong zu spielen, anstatt die TCP Window Size auszunutzen. Wenn dann andere Applikationen dieselben Treiber verwenden, ohne aber ihrerseits die für sie richtigen Parameter zu setzen, »krepieren« diese Applikationen elend. Microsoft muss wenigstens insofern in Schutz genommen werden (was auch nicht immer leicht fällt), als tatsächlich seitens Microsoft die Programmierer darauf hingewiesen werden, dass hier aufgepasst werden muss.

7.8.7

TCP: Checksum

Die TCP-Prüfsumme deckt neben dem Header auch die Daten ab. Die einzige Auffälligkeit ist, dass Analyzer solche Pakete, die nicht in ihrer vollen Länge >>> NEW TECH

313

Kapitel 7 • TCP/IP-Grundlagen

aufgenommen wurden (weil der Eingangspuffer des Analyzer zu klein eingestellt war), auch nicht auf die korrekte Prüfsumme hin untersuchen können. Es erscheint dann schon mal eine Anzeige wie: »Checksum incorrect or frame is sliced« – entweder sei die Prüfsumme defekt oder das Paket liege nur verkürzt vor.

7.8.8

TCP: Urgent Pointer

Der Wert dieses Parameters weist als Pointer auf besonders wichtige Daten. Die Verwendung ist extrem selten und kann daher vernachlässig werden. Es kann aber zu Inkompatibilitäten kommen, wenn der Urgent Pointer verwendet wird, da sich zwei Deutungsweisen entwickelt haben: Urgent Pointer nach BSD. Urgend Pointer nach RFC 1122 Dies kann in der WinNT Registry eingestellt werden. ■ ■

WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ TcpUseRFC1122UrgentPointer

7.8.9

TCP: Maximum Segment Size (Option)

Zu Beginn einer TCP-Verbindung einigen sich die beiden Teilnehmer auf die kleinste gemeinsame Paketgröße, um den Endgeräten ein IP Fragmenting in ihrem jeweiligen IP Subnet zu ersparen. Das muss nicht notwendig so sein; es kann dem Treiber auch vorgeschrieben werden, alle Verbindungen außerhalb des aktuellen IP-Subnetzes (also außerhalb des LAN-Segment) mit der einheitlichen TCP Segment Size von 576 Byte zu bedienen (EnablePMTUDiscovery). Scheitert der Datenfluss daran, dass auf Transitstrecken fragmentiert werden müsste, dieses aber nicht erfolgt (erfolgen kann), ist von erheblichem Belang, dass der TCP-Treiber diesen Defekt selbstständig erkennen kann. Es ist absolut kurios, dass diese Erkennung »schwarzer Löcher« per Voreinstellung auf AUS gestellt ist (EnablePMTUBHDetect)! Sie sollten also im Zweifel die WinNT-Rechner entsprechend kontrollieren. Zur erweiterten Fähigkeit von TCP, Fehler im Bereich der Router zu erkennen (und nicht nur in der Fragmentierung), sollte auch der Paramter gesetzt sein, der das Auffinden toter Router erlaubt (EnableDeadGWDetect). Zwischen der TCP MSS und der physikalischen MTU besteht ein enger Zusammenhang.

314

>>> NEW TECH

Im Fokus des Analyzers: TCP

WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ EnableDeadGWDetect HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ EnablePMTUBHDetect HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ EnablePMTUDiscovery

Siehe auch zur IP-Fragmentierung die Abschnitte 7.7.3 (IP Total Length) ff.

7.8.10 TCP Expertendiagnose Bereits in Abschnitt 7.8.3 wurde auf wichtige Fähigkeiten der Expertensysteme eingegangen (und am Beispiel geschildert), die wichtigsten Fehler in der TCP Data Flow Control automatisch zu erkennen. Es ist dem LAN-Analysten dringend zu raten, jede TCP-Analyse mit einer solchen automatischen Auswertung zu beginnen – und zwar auch dann, wenn er sich seiner Sache sicher glaubt. Niemand kann Millionen von TCP-Paketen von Hand durchsehen, das ist unmöglich.

Abbildung 7.39: TCP Expertenanalyse: Definition von Schwellwerten zur Qualitätssicherung

Die Expertenanalyse kann bei manchen Produkten aber noch weitergehend verwendet werden – nämlich zur Qualitätssicherung der laufenden Datenströme. Das folgende Beispiel entstammt dem LANdecoder32 (Triticom), steht hier aber nur stellvertretend auch für andere Produkte, die ähnlich arbeiten. >>> NEW TECH

315

Kapitel 7 • TCP/IP-Grundlagen

Über Schwellwerte wie die hier in Abbildung 7.39 kann genau gesteuert werden, wie viel Fehlertoleranz man selber akzeptieren möchte. So würde man die Schwellwerte bei WAN-Verbindungen eher höher ansetzen (wie hier im Beispiel), bei LAN-Verkehr aber deutlich darunter.

7.9 Im Fokus des Analyzers: UDP UDP-Fehler, oder solche, die unmittelbar mit UDP zu tun hätten, sind sehr selten. UDP ist so simpel konstruiert, dass es kaum Gelegenheit zu Fehlern gibt.

Abbildung 7.40: UDP-Header mit IP-Multicast (hier: Cisco)

Da UDP nur ungesicherten Verkehr überträgt, kennt es auch keine Sicherungsmechanismen (außer der Prüfsumme). Zu den wenigen Auffälligkeiten rund um UDP gehören: UDP – der Träger von SNMP (aber nicht allein!) SNMP wird nicht von TCP, sondern von UDP übertragen – also verbindungslos. Das hat sich auch schon allgemein herumgesprochen. Allerdings hat sich nicht verbreitet, dass ein Filter auf UDP nicht notwendig alle SNMP-Nachrichten »einfängt«, da in Novell-Umgebungen auch SNMPüber-IPX möglich ist. Nicht jeder Analyzer unterstützt Filter auf SNMP unter Einschluss dieser Variante. Sollte das bei Ihrem Analyzer der Fall sein, müssen Sie andere Varianten wählen; in aller Regel setzen Sie dann einen wilden Filter (ohne feste OffsetAngabe) auf einen für SNMP typischen Nachrichteninhalt, so z.B. den SNMP Community String.

316

>>> NEW TECH

Im Fokus des Analyzers: UDP

Dienste, die wahlweise über UDP oder TCP laufen können Dienste wie beispielsweise NFS können sowohl über UDP wie auch TCP arbeiten. Dies wird spätestens dann kritisch, wenn ■

■

gerade im Falle von NFS über UDP gearbeitet wird, obwohl TCP dringend angeraten wäre (wegen der Absicherung der Übertragungen), dieses aber niemand merkt, weil niemand an diese Möglichkeit gedacht hat; gleichzeitig über beide Transportprotokolle gearbeitet wird.

Fehler: Doppelte Zugriffe Der Autor konnte erst vor kurzem (Sommer 1999) bei einem Kunden beobachten, wie ein WinNT-Server, der als Windows Terminal Server (WTS) arbeitete und der sich laufend Daten von einem Unix-Rechner beschaffen musste, Folgendes tat: ■

■ ■ ■ ■

■

Auf Anforderung seitens eines WTS-Clients versuchte der WinNT-Server NFS-Zugriffe auf den Unix-Server sowohl via UDP als auch TCP aufzubauen. Per TCP wurde die NFS-Verbindung hergestellt und die Daten wurden übertragen. Während das lief, pollte der WinNT-Server unverdrossen aber weiter mit UDP denselben Unix-Server an. Dieser antwortete laufend auf jedes UDP-NFS-Paket mit »ICMP: Destination Unreachable/Service Unavailable« (siehe 7.6.1) – wie es sich gehört. Der WinNT-Server ließ sich dadurch aber nicht beirren. Er ließ sich eigentlich von überhaupt nichts beirren (und darin eben »typisch WinNT«!) – noch nicht einmal von dem Faktum, dass per TCP-NFS die angeforderten Daten längst eingetroffen waren. Der WinNT-Server hörte niemals mehr auf, per UDP-NFS den Unix-Server anzupollen. Der WinNT-Server bzw. sein UDP-Treiber »vergaßen« niemals mehr, dass da – angeblich – Daten vom Unix-Server zu holen waren ...

Dies aber ist nicht wirklich ein UDP-Fehler, sondern ... nun ... ein MicrosoftFehler? ... ein WinNT-Fehler ....? Die Grenzen sind fließend. Der Autor kann nicht verhehlen, solche Fehler stets wieder mit ungeteilter Freude anzusehen, weil sie ... ja, weil sie eben für WinNT so überaus typisch sind... Noch ein seriöser Nachtrag: Es können UDP-Ports auch gezielt außer Kraft gesetzt werden. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip\UdpAllowedPorts

>>> NEW TECH

317

Kapitel 7 • TCP/IP-Grundlagen

7.10 BOOTP/DHCP 7.10.1 BOOTP – Bootstrap Protocol Mittels BOOTP kann ein IP-Client, dessen Treiber keine lokale Konfiguration vorfindet, seine eigene IP-Adresse sowie die Router-Adresse abfragen. BOOTP arbeitet über IP-UDP (verbindungslos); die Abfrage wird als LANBroadcast (0xFFFFFFFFFFFF) und IP-Broadcast (255.255.255.255) gesendet.

Abbildung 7.41: BOOTP-Request eines IP-Clients

In Abbildung 7.41 und 7.42 ist zu sehen, wie der IP-Client seinen IP-Broadcast mit der IP-Absenderadresse 0.0.0.0 versendet. Die eigene IP-Adresse soll ja gerade abgefragt werden. Zugleich ist zu sehen, dass der BOOTP-Request die MAC-Adresse des IP-Clients enthält (Client Hardware Address) – dem BOOTP-Server wird hierdurch Gelegenheit gegeben, dem IP-Client ggf. keine beliebige, gerade freie IP-Adresse dynamisch zuzuweisen, sondern für jede MAC-Adresse eine fest vorgegebene IP-Adresse zu vergeben.

318

>>> NEW TECH

BOOTP/DHCP

Abbildung 7.42: BOOTP-Reply des BOOTP-Servers an den IP-Client

Untypisch an der Antwort in Abbildung 7.42 ist, dass der BOOTP-Reply des BOOTP-Servers bereits an die IP-Adresse des IP-Clients adressiert wird – der kennt diese ja noch nicht! Es ist allgemein üblich, den BOOTP-Reply ebenfalls per IP-Broadcast-Adresse zurückzugeben, wie es das Beispiel in Abbildung 7.43 zeigt. Es ist weiterhin zu sehen, dass BOOTP im letzten Bild zusätzliche Daten transportiert – hier handelt es sich um DHCP-Daten.

7.10.2 DHCP – Dynamic Host Configuration Protocol In Abbildung 7.43 ist zu sehen, dass der DHCP-Anhang in den BOOTP-Paketen vom Analyzer nicht aufgelöst wird. Dies ist leider bei mehreren Produkten der Fall, etwa bei dem Observer (Network Instruments) oder beim LANdecoder32 (Triticom); vermutlich liegt dies an der sehr variablen Struktur des DHCP-Aufbaus.

>>> NEW TECH

319

Kapitel 7 • TCP/IP-Grundlagen

Abbildung 7.43: BOOTP-Dialog mit IP-Broadcast-Adressen

Allerdings ist der sog. Hex-Dump des DHCP-Teils verhältnismäßig leicht lesbar. Man drucke sich den RFC-2132 aus; mit diesem Dokument in der Hand geht es sehr schnell. Mit Ausnahme des lästigen Umrechnens der IP-Adressen und Zeit-Angaben geht das Auslesen der DHCP-Werte schnell; aber auch das Umrechnen der IP-Adressen geht mit einiger Übung schnell (Sie kennen Ihre IP-Adressen schließlich), und die Hex-Zeitwerte werden mit dem Windows»Taschenrechner« von Hex in Dezimal umgewandelt und durch 86.400 geteilt – dann erhält man die Zahl der Tage (oder der Hex-Wert wird durch 0x015180 geteilt).

Abbildung 7.44: Hex-Dump der DHCP-Daten in einem BOOTP-Reply

320

>>> NEW TECH

BOOTP/DHCP

Die DHCP-Daten in Abbildung 7.44 lassen sich u.a. wie folgt lesen: Es wird jeweils der Hex-Code der DHCP-Option angegeben, dann die Länge des Wertes, sodann der Wert selber. So finden sich in diesem Falle: DHCP Bytes

Code (dez.)

Länge (dez.)

Options-Wert (Hex-Bytes)

Bedeutung bzw. Inhalt der DHCP-Option

0x3A04

58

4

0x0001FA40

Timer T1 Renewal (hier: 1,5 Tage)

0x3B04

59

4

0x000375F0

Timer T2 Rebinding (2,625 Tage)

0x3304

51

4

0x0003F480

IP Lease Time (hier: 3 Tage)

0x3604

54

4

0xC0A86F01

IP-Adresse des DHCP-Servers

0x0104

01

4

0xFFFFFF00

IP Subnet Mask 255.255.255.0

0x2C08

44

8

0xC0A86F66

1. WINS (NBNS) Server

0xC0A86F01

2. WINS (NBNS) Server

0x2E01

46

1

0x08

WINS Node Type = 8 = Hnode

0xFF

(Ende von DHCP)

Tabelle 7.21: DHCP-Auflösung am Beispiel der Abbildung 7.44

Es springt sofort ins Auge, dass die Reihenfolge der DHCP-Optionen keine Rolle spielt; dies dürfte auch der Grund sein, warum es den Programmierern der Analyzer schwerfällt, eine klare Darstellung von DHCP zu bewerkstelligen. Es folgt eine Tabelle mit den DHCP-Optionen; eine eigene Spalte zeigt an, welche Optionen davon am WinNT DHCP-Server zur Rückgabe an die DHCPClients konfiguriert werden können, was mit JA gekennzeichnet ist. Mit JA+ wird angezeigt, dass der Wert von Windows-DHCP-Clients verstanden wird. Nicht alle DHCP-Parameter werden von Windows-DHCP-Clients verstanden! Option hex

Option dez.

Länge

Konfiguierbar Bedeutung beim WinNT DHCP Server

0x01

001

4

(automatisch)+ IP Subnet Mask

0x02

002

4

JA

Time Offset

0x03

003

n

JA+

IP-Adresse(n): Router/Gateways

0x04

004

n

JA

IP-Adresse(n): Time Server

0x05

005

n

JA

IP-Adresse(n): Name Server

0x06

006

n

JA+

IP-Adresse(n): DNS Server

0x07

007

n

JA

IP-Adresse(n): Log Server

0x08

008

n

JA

IP-Adresse(n): Cookie Server

0x09

009

n

JA

IP-Adresse(n): LRP Server

0x0A

010

n

JA

IP-Adresse(n): Impress Server

Tabelle 7.22: DHCP Options

>>> NEW TECH

321

Kapitel 7 • TCP/IP-Grundlagen

Option hex

Option dez.

Länge

Konfiguierbar Bedeutung beim WinNT DHCP Server

0x0B

011

n

JA

IP-Adresse(n): Resource Loc. Srv.

0x0C

012

n

JA

Host Name/Computer Name

0x0D

013

2

JA

Boot File Size

0x0E

014

n

JA

Merit Dump File

0x0F

015

n

JA+

Domain Name

0x10

016

n

JA

IP-Adresse(n): Swap Server

0x11

017

n

JA

Root Path

0x12

018

n

JA

Extensions Path

0x13

019

1

JA

J/N: IP Forwarding

0x14

020

1

JA

J/N: Non-Local Source Routing

0x15

021

n

JA

Policy Filter Mask

0x16

022

2

JA

Max. Datagram Reassembly Size

0x17

023

1

JA

IP Default Time-To-Live (TTL)

0x18

024

4

JA

Path MTU Aging Timeout

0x19

025

n

JA

Path MTU Plateau Table

0x1A

026

2

JA

Interface MTU (Max.Transm.Unit)

0x1B

027

1

JA

J/N: All Subnets are Local

0x1C

028

4

JA

IP-Adresse: Broadcast Address

0x1D

029

1

JA

J/N: Perform Mask Discovery (ICMP)

0x1E

030

1

JA

J/N: Mask Supplier Option

0x1F

031

1

JA

J/N: Perform Router Discovery

0x20

032

4

JA

Router Solicitation Address (ICMP)

0x21

033

n

JA

Static Route Option

0x22

034

1

JA

J/N: Trailer Encapsulation

0x23

035

4

JA

ARP Cache Timeout

0x24

036

1

JA

J/N: Ethernet Encapsulation

0x25

037

1

JA

TCP Default Time-To-Live (TTL)

0x26

038

4

JA

TCP Keep-Alive Interval

0x27

039

1

JA

J/N: TCP Keep-Alive Garbage

0x28

040

n

JA

NIS Domain Name

0x29

041

n

JA

IP-Adresse(n): NIS Server

0x2A

042

n

JA

IP-Adresse(n): NTP Server

Tabelle 7.22: DHCP Options (Forts.)

322

>>> NEW TECH

BOOTP/DHCP

Option hex

Option dez.

Länge

Konfiguierbar Bedeutung beim WinNT DHCP Server

0x2B

043

n

JA

Vendor Specific Informationi

0x2C

044

n

JA+

IP-Adresse(n): WINS-NBNS Server

0x2D

045

n

JA

IP-Adresse(n): NBDD Server

0x2E

046

1

JA+

WINS-NBT Node Type (1,2,4,8)

0x2F

047

n

JA+

NetBIOS Scope ID (RFC 1001,1002)

0x30

048

n

JA

X Window System Font Server

0x31

049

n

JA

X Window System Display Manager

0x32

050

4

--

IP-Adresse: Request IP Address (Client)

0x33

051

4

JA+

IP Address Lease Time (Client/Server)

0x34

052

1

--

DHCP Option Overload (1,2,3)

0x35

053

1

--

DHCP Message Type (1,2,3,4,5,6,7,8)

0x36

054

4

--

IP-Adresse: DHCP Server (Client/ Server)

0x37

055

n

--

DHCP Parameter Request List (Client)

0x38

056

n

--

DHCP Message (Failure Notification)

0x39

057

2

--

Maximum DHCP Message Size

0x3A

058

4

JA+

Timer T1/Renewal

0x3B

059

4

JA+

Timer T2/Rebinding

0x3C

060

n

--

Vendor Class ID

0c3D

061

n

--

Client ID (möglich: MAC Adresse)

0x3E

062

--

--

--

0x3F

063

--

--

--

0x40

064

n

JA

NIS+ Domain Name

0x41

065

n

JA

IP-Adresse(n): NIS+ Server

0x42

066

n

--

TFTP Server Name

0x43

067

n

--

Bootfile Name

0x44

068

n

JA

IP-Adresse(n): Mobile Home Agents

0x45

069

n

--

IP-Adresse(n): SMTP Server

Tabelle 7.22: DHCP Options (Forts.)

>>> NEW TECH

323

Kapitel 7 • TCP/IP-Grundlagen

Option hex

Option dez.

Länge

Konfiguierbar Bedeutung beim WinNT DHCP Server

0x46

070

n

--

IP-Adresse(n): POP3 Server

0x47

071

n

--

IP-Adresse(n): NNTP Server

0x48

072

n

--

IP-Adresse(n): WWW Server

0x49

073

n

--

IP-Adresse(n): Finger Server

0x4A

074

n

--

IP-Adresse(n): IRC Server

0x4B

075

n

--

IP-Adresse(n): StreetTalk Server

0x4C

076

n

--

IP-Adresse(n): StreetTalk STDA Server

--

--

--

--

(keine weiteren Optionen vergeben)

Tabelle 7.22: DHCP Options (Forts.)

Die entscheidenden Werte, die in der Analyse eine Rolle spielen, sind: ■ ■ ■ ■ ■

IP Address IP Subnet Mask IP Default Gateway(s) WINS Server WINS Node Type

Hinweise zu den Einstellungen am DHCP-Server. Für mehr benutzen Sie bitte: Microsoft Windows NT Server Version 4 – Die technische Referenz (Microsoft Press 1998), S. 473 ff.

7.11 SNMP/RMON Da die Arbeit mit dem LAN-Analysator beschwerlich ist, wenn das zu untersuchende LAN-Segment in einer fernen Niederlassung liegt, wird es wichtig, mit den Mitteln der Ferndiagnose zu arbeiten. Dies geschieht mit: ■ ■

SNMP – Simple Network Management Protocol RMON – Remote Network MONitoring

7.11.1 SNMP: Befehls- und Abfragesprache SNMP ist eine Befehls- und Abfragesprache, die ursprünglich zur Überwachung von Routern entwickelt wurde.

324

>>> NEW TECH

SNMP/RMON

Da mit SNMP nur Zählerstände abgefragt bzw. Betriebsparameter neu gesetzt werden können, sind die Mittel zur Netzwerkanalyse äußerst begrenzt: Es hilft nicht sonderlich, einen Router zu fragen, wie viele IP-Pakete er seit letzter Woche, fünf Uhr sechsundsechzig, versendet hat. Daher wurde als Zusatz RMON eingeführt. Zu SNMP sind wenige Auffälligkeiten zu vermelden:

7.11.2 SNMP-over-IPX Bereits im vorigen Abschnitt 7.9 wurde darauf verwiesen, dass SNMP zwar überwiegend, aber nicht nur über IP-UDP transportiert wird. Ein seltener, aber manchmal zu sehender Exot ist SNMP-über-IPX.

7.11.3 SNMP und CMIP Manchmal ist zu sehen, wie zwei ungleiche Paare versuchen miteinander zu kommunizieren: ■ ■

SNMP-Komponenten CMIP-Komponenten

SNMP entstand ursprünglich als reine Übergangslösung, bis das eigentlich erwartete Common Management Information Protocol (CMIP) da sein würde. In den 80er Jahren wurden die sog. ISO-Protokolle (auch OSI-Protokolle genannt) über die UNO zu weltweiten Standards erhoben; die Regierungen Europas und Nordamerikas verpflichteten sich, alle öffentlichen Datennetze mit diesen Protokollen auszurüsten. Zu den letzten Überresten dieser Dinosaurier-Protokolle gehört CMIP – und manchmal sieht man, wie sich Komponenten Meldungen zuzusenden versuchen. Das ist völlig unschädlich und es erfolgt in aller Regel auch ohne Absicht, weil bei manchen Geräten die Einstellungen im Hintergrund diese Dialogversuche verursachen. Das Einfachste ist, CMIP einfach abzuschalten – es ist extrem unwahrscheinlich, dass Ihr Netz noch damit arbeitet.

7.11.4 SNMP Community String public/private Wo immer noch der vom Hersteller ab Werk vorgegebene Standardwert public für den SNMP Community String verwendet wird (Lesezugriffe), gehört der schnell ersetzt! Jeder Hacker kennt public und wird hiermit als Allererstes versuchen, sich Zugang zu den zentralen Systemen im Netz zu verschaffen.

>>> NEW TECH

325

Kapitel 7 • TCP/IP-Grundlagen

Ist dann auch noch der Standardwert private für aktive Eingriffe gegeben, kann ein Hacker das ganze Netz ausknipsen. Es reicht, einem zentralen Router alle Konfigurationen zu löschen und ihn dann per Kaltstart außer Betrieb zu setzen. Gleiches gilt für die immer gleichen Community Strings z.B. von Cisco.

7.11.5 RMON: Ferndiagnose/Verkehrsanalyse Der RMON-Prozess (RMON-Agent) einer aktiven Netzwerkkomponente (Router, Switch, Server, Probe) kann sehr vieles davon leisten, was normalerweise der klassische LAN-Analysator tut. Hierbei ist zu unterscheiden zwischen: ■ ■

RMON I – Statistik RMON II – Paketanalyse

Die Einstellungen zur LAN-Messungen werden via SNMP übertragen. Sollen Datenpakete eingelesen werden, so sendet der RMON-Agent in codierter Form die Captured Frames via SNMP an die RMON-Console. RMON-Analyse hat den sehr großen Vorteil, dass die Reaktionszeiten ganz drastisch verkürzt bzw. dass Vorwarnzeiten gewonnen werden können. Gleichwohl darf nicht verkannt werden, dass in schwierigen Fällen die Messung vor Ort, also mit LAN-Analysator unmittelbar an der Leitung, letztlich doch unverzichtbar ist.

7.11.6 HS-RMON Zuletzt sei auf das von Chevin entwickelte HS-RMON verwiesen, das eine ganz erhebliche Leistungssteigerung gegenüber Standard-RMON aufweist, indem Kompression und Übermittlung der Daten erheblich verbessert wurden – darum die Bezeichnung High Speed RMON.

326

>>> NEW TECH

Kapitel 8 OSI-Schichten 3 und 4: TCP/IP Die Analyse der Oldtimer TCP und IP dürfte, so scheint es, gar keine große Sache sein. Seit ziemlich genau 20 Jahren nun liegen die grundlegenden RFCs vor und seit Ende der 80-er Jahre sind dem Prinzip nach LAN-Analyzer verfügbar, wie wir sie heute kennen. Und doch ..., da wird viel mit Wasser in den Weinschläuchen gehandelt.

8.1 Allgemeine (und fällige) Analyzer-Schelte Der Verfasser ist seit Mitte der 90-er Jahre restlos enttäuscht über die völlig mangelhafte TCP/IP-Analyse der so genannten (und gelegentlich selbst ernannten) Marktführer. Das, was da dem Kunden als »TCP/IP-Analyse« verkauft wird, hat in vielen Fällen nicht viel mehr Wert als ein Placebo beim Arzneimitteltest: »Hauptsache, bunt!« Hauptsache, die Pie Charts und Top Talker Graphs sind schön bunt und Hauptsache auch, dass ab und an eine TCP Retransmission den fälligen Leistungsnachweis erbringt. Das alles steht an der Grenze zum Lächerlichen. Es gibt wirklich viele FehlerSzenarien, die in diesen Tagen von erheblichem Belang sind, die von keinem der handelsüblichen Analyzer sichtbar bzw. zuverlässig zugänglich und nachweisbar gemacht werden. Da der Verfasser seit 1992 praktisch ausschließlich von LAN-WAN-Analyse lebt (und damit der dienstälteste Freischaffende auf diesem Gebiet sein dürfte) und da er in der Ausübung seines Berufs extrem von der Tauglichkeit seiner Werkzeuge abhängt, begann er schon 1996 damit, ein eigenes Experten-System zur Auswertung von Messdaten zu programmieren. Unter MS-DOS hieß das noch LANreport, unter Windows heißt es heute TraceMagic. Seither sind ihm Befunde bzw. Nachweise möglich, von denen Sniffer und Co. nur träumen, und vor allem sind ihm so kurze Bearbeitungszeiten möglich, dass er in der Regel im Laufe des ersten Tages beim Kunden eine (fast) vollständige Diagnostik vorlegen und auf CD-ROM überlassen kann – (fast) egal, um welche Fehler es sich handelt.

>>> NEW TECH

327

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

Das setzt ein Werkzeug voraus, das große Datenmengen automatisch verarbeiten kann, aber auch die aktuellen Fehler unserer Tage kennt und sichtbar macht. Genau hier liegt das Problem: Die anderen Analyzer-Hersteller beten artig das kleine Einmaleins der RFCs herunter, arbeiten aber ansonsten reichlich an der Wirklichkeit vorbei. Insbesondere die WAN-Analyse ist bei den meisten Herstellern ein glatter Witz und das hat Gründe: WAN-Provider haben es sich längst zur Angewohnheit gemacht, keine ICMPMeldungen ihrer Router an die Kunden herauszugeben, das heißt die eigenen Router-ICMP-Pakete werden am Übergang zum Campus-LAN des Kunden herausgefiltert. Ein Schelm, wer Arges dabei denkt! Offenkundig geht es darum, dem Kunden keine Chance zu geben, die ggf. vorhandenen Missstände in der WAN-Wolke des Providers mittels dieser ICMP-Meldungen nachweisbar zu machen. Wo kämen wir denn da hin! Die am Markt gängigen Analyzer jedoch sind dringend auf diese ICMPMeldungen angewiesen. Fehlen sie, ist die Diagnostik so weit eingeschränkt, dass oft die verbleibenden Hinweise dermaßen dürftig sind, dass keine Aussagen von Belang mehr möglich sind. Die gängigen Fähigkeiten der Analyzer beschränken sich weitgehend auf die folgenden Punkte (es werden die wichtigsten Funktionen aufgezählt, die üblicherweise unterstützt werden): ■ ■ ■ ■ ■ ■

ICMP-Meldungen IP: Niedrige TTL-Werte (Time-To-Live; nicht bei allen Analyzern) TCP: fehlende Pakete bzw. Sequences (nicht bei allen Analyzern) TCP: Retransmissions (wiederum Hinweis auf Paketverluste) TCP: Antwortzeiten (Round Trip Delay, Slow Response, Fast Response) TCP: Keep Alive-Pakete (Sitzungserhalt bei vorübergehender Sendepause)

Viel mehr ist da meistens nicht drin – oft sind darüber hinaus gehende Funktionen mehr oder weniger nur Schau, um wenigstens noch ein bisschen Eindruck zu machen. Der Verfasser verdient weitgehend sein Geld damit, dann in Aktion zu treten, wenn andere Dienstleister, die mit Sniffer und Co. arbeiten, schon zuvor tätig waren und versagt haben. Da das nun schon seit zehn Jahren so geht, dürfte ein Ende nicht absehbar sein. Das soll sagen: Es müssen tatsächlich gravierende Mängel in den herkömmlichen Analyzern vorhanden sein, wenn ein ganzes Berufsbild auf diesen Mängeln aufsetzt. So gesehen, will der Verfasser nicht klagen: Je mangelhafter die Placebo-Systeme Dritter arbeiten, um so besser für ihn und sein Geschäft. Mag sein, aber für die Kunden ist das ein unhaltbarer Zustand. Deswegen fiel ja auch in 2001 die Entscheidung, das Experten-System TraceMagic von Synapse:Networks bzw. des Verfassers der Öffentlichkeit durch Verkauf zugänglich zu machen –, auch wenn dies eine Einbuße an Wissensvorsprung mit sich bringt. Um zu sehen, was tiefe IP-Analyse wirklich bedeutet, sei auf Kapitel 15 hingewiesen, nämlich eine zur Layer-7-Analyse gehörende Voice over IP Fallstudie. Wer immer versuchen wollte, die darin beschriebenen diagnostischen Metho-

328

>>> NEW TECH

Verweis auf die anderen Kapitel

den in seinem eigenen Analyzer wiederzufinden oder gar nachzubilden, dürfte bald entnervt aufgeben – weil der Analyzer das alles nicht unterstützen dürfte.

8.2 Verweis auf die anderen Kapitel Abgesehen davon, dass dieses TCP/IP-Kapitel einen Abriss vieler (nicht aller) TraceMagic-Funktionen liefert, ist grundsätzlich auf die Kapitel zur Analyse der Namensdienste sowie der Applikations-Schicht zu verweisen, weil viele wichtige Praxisbeispiele der TCP/IP-Analyse dort eingebunden sind. Das ist kein Nachteil dieses Kapitels, sondern insgesamt ein Vorteil dieses Buches, da versucht wird, eine möglichst ganzheitliche Sicht auf die Messdaten zu gewinnen, indem auch – und gerade – Wechselwirkungen zwischen den verschiedenen Protokollen und Netzwerk-Schichten in den Beispielen und Fallstudien sichtbar gemacht bzw. nachgewiesen werden.

8.3 Vorgehensweise in diesem Kapitel Dieses Kapitel fasst kurz die Analyse-Funktionen zusammen, die über TraceMagic/SpiderMagic verfügbar sind. Nicht wenige dieser Funktionen sind in herkömmlichen Analyzern nicht verfügbar. Sie sind zum Teil unverzichtbar insbesondere bei komplizierten WAN-Fehlern. Die folgende Darstellung folgt dem Inhalt der TraceMagic-Knowledgebase (Wissensdatenbank). Insgesamt werden die Darstellungen der Erstausgabe des Networker’s Guide (Erst-Ausgabe April 2000, siehe beiliegende CD-ROM) vorausgesetzt.

8.4 ICMP: Kurze Übersicht Die ICMP-Meldungen insbesondere von Routern sind wichtig, um WANFehler zu erkennen. Da viele WAN-Provider jedoch die ICMP-Pakete vor Übertritt in die angeschlossenen Campus-LANs der Kunden herausfiltern, müssen andere Wege gefunden werden, um zum Beispiel sog. Black Hole-Szenarien zu erkennen. TraceMagic wendet spezielle Auswertungsmethoden bei TCP und IP an, um auch ohne ICMP-Meldungen versteckte WAN-Fehler nachzuweisen. In Tabelle 8.1 finden Sie eine kurze Übersicht der für IP (Version 4) gültigen ICMP-Meldungen. Eine ausführliche Darstellung hierüber ist in der Erstausgabe des Networker's Guide (April 2000, siehe beiliegende CD-ROM) nachzulesen.

>>> NEW TECH

329

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

ICMP Type/Code

Bedeutung

ICMP 08/00

Echo Request

ICMP 00/00

Echo Reply

ICMP 03/00

Destination Unreachable: Network Unreachable

ICMP 03/01

Destination Unreachable: Host Unreachable

ICMP 03/02

Destination Unreachable: Protocol Unavailable

ICMP 03/03

Destination Unreachable: Port Unavailable

ICMP 03/04

Destination Unreachable: Fragmentation Needed

ICMP 03/05

Destination Unreachable: Source Route Unavailable

ICMP 03/10

Destination Unreachable: Communication Prohibited

ICMP 04/00

Source Quench

ICMP 05/00

Redirect For IP Network

ICMP 05/01

Redirect For IP Host

ICMP 05/02

Redirect For Service/Network

ICMP 05/03

Redirect For Service/Host

ICMP 09/00

Router Advertisement

ICMP 0A/00

Router Solicitation

ICMP 0B/00

Time Exceeded: TTL = 0/Time-To-Live Expired

ICMP 0B/01

Time Exceeded: Reassembly Timer Expired

ICMP 0C/00

Parameter Problem

ICMP 0D/00

TimeStamp Request

ICMP 0E/00

TimeStamp Reply

ICMP 0F/00

Information Request

ICMP 10/00

Information Reply

ICMP A1/00

Address Format Request

ICMP A2/00

Address Format Reply

Tabelle 8.1: ICMP Type/Code (für IPv4) und Bedeutung (kurze Übersicht)

8.5 IP: Fehler und Symptome Die folgenden Abschnitte umfassen die wichtigsten Ereignisse und Fehler, die bei der IP-Analyse eine Rolle spielen, vor allem bei der WAN-Analyse.

8.5.1

IP Corrupted Packet

Insbesondere bei Ethernet kann sich ereignen, dass der IP-Header nur noch fragmentarisch erhalten oder verfälscht ist. Bei Shared-Media-Ethernet bzw. Half-Duplex-Ethernet kann dies die Folge von Kollisionen sein. Es kann aber

330

>>> NEW TECH

IP: Fehler und Symptome

auch sein, dass Switches LAN-Frames verfälschen; Beispiele hierzu sind im Kapitel über die Layer-2-Analyse sowie in der Layer-7-Fallstudie zu Voice over IP zu finden. Wird erkannt, dass der IP-Header nicht vollständig vorhanden ist, sondern nur fragmentarisch (teilweise), weil der MAC-Frame zu kurz ist, erkennt dies TraceMagic als ein Corrupted Packet.

8.5.2

IP Packet: MAC Multiple Tx/Duplicate IP Header

SpiderMagic erkennt, wenn innerhalb der jeweils letzten zehn Pakete, die von einem IP-Absender auf der Leitung zu sehen sind, zwei (oder mehr) IP-Header identisch sind. Die Identität bezieht sich hierbei nur auf den IP-Header, nicht auf den MAC-Frame (Header/Trailer). Mögliche Ursachen sind: ■

■ ■

Eine Komponente (LAN-Adapter, Switch, Router) sendet einen MACFrame mehrfach aus seinem Sende-Puffer (Tx Buffer). Dies kommt selten vor, ist aber immer wieder mal zu beobachten (siehe Fallstudie zu Voice over IP) und stellt in jedem Falle einen Defekt dar. Eine seltene Variante von Mehrfach-Übertragungen sind Token-Ring Source-Route Frames, bei denen ggf. über Source-Route Broadcasts (ARB, SRB) verschiedene MAC-Frames unterwegs sein können, deren innewohnender IP-Header identisch ist. Ein Router leitet ein IP-Paket weiter, ohne den TTL-Wert zu mindern und die Prüfsumme neu zu berechnen. Dies wäre ein klarer Defekt des Routers. Bei Token-Ring/FDDI: Ein Paket kreist möglicherweise mehrfach im Ring, ohne vom Ring genommen zu werden. In diesem Falle wären im Trace ebenfalls mehrere identische IP-Header zu sehen. Als Grund wäre ein Defekt in der LAN-Hardware gegeben (Adapter, Bridges, Switches, Router).

8.5.3

IP Packet: MAC Multicast/Broadcast

IP-Pakete können und dürfen als MAC-Broadcast oder MAC-Multicast versendet werden. Gleichwohl ist es hilfreich, ggf. sogar wichtig, hierüber näher Aufschluss zu erlangen, da sich hier unerfreuliche Fehler einschleichen können. ■ ■

Ein zu hoher Anteil der Broadcasts/Multicasts am Gesamtaufkommen des Datenverkehrs gibt oft Hinweise auf Fehler. TCP-Pakete, die als Broad- oder Multicasts versendet werden, sind meistens insofern fehlerhaft, als sie nur als MAC-Unicasts auf der Leitung sein dürften. TCP ist ein verbindungsorientiertes Transportprotokoll, das eben nicht über Broadcasts arbeiten soll – im Gegensatz zu UDP, das (nicht nur, aber auch) für Broadcasts vorgesehen ist.

>>> NEW TECH

331

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

TCP-Pakete, die als MAC-Multicasts oder MAC-Broadcasts übertagen werden, sind für herkömmliche LAN-Analyzer gegenstandslos: Das Szenario wird nicht berücksichtigt, da es in den RFCs nicht vorkommt. Über den praktischen Wert solcherlei Programmierung muss man dann wohl kaum noch Worte verlieren. TraceMagic verfügt demnach über eine detaillierte Aufschlüsselung aller IPBroadcasts und IP-Multicasts.

8.5.4

IP Version ungleich v4/v6

Da zurzeit nur die IP-Versionen 4 (LAN) und 6 (WAN) gebräuchlich sind, können alle Versions-Werte außer 4 oder 6 als fehlerhaft angesehen werden. So wurden Kyocera-Printer (Sommer 2001) dabei beobachtet, IPv4-Pakete zu senden, in denen das erste IP-Oktett auf 0x00 gesetzt war, was missverständlich als Version = 0 und HeaderLength = 0 zu deuten war. Hierbei handelte es sich nicht wirklich um den Versuch, IP-Pakete mit der scheinbaren Version = 0 zu senden, sondern um einen Gerätefehler, der zufällig diese Wirkung hatte.

8.5.5

IP Header Length < 20 Octets

Die Länge des IP-Headers beträgt im Normalfall mindestens 20 Oktette und ist in diesem selber angegeben. Ist diese Längenangabe mit einem Wert kleiner 20 versehen (im Hex-Code kleiner 0x05), so muss ein Fehler vorliegen. Dieses Ereignis kommt in der Regel nur dann vor, wenn der Inhalt der LANFrames verstümmelt wurde und sich hierüber ein solcher scheinbarer Wert ergibt.

8.5.6

IP ToS / Type of Service

Die IP-ToS-Parameter waren lange Jahre praktisch nicht mehr in Gebrauch. Im Zuge der Projekte rund um Voice over IP taucht der Gebrauch hier und da wieder auf, um laufzeitempfindliche Applikationen von Routern bevorzugt behandeln zu lassen.

8.5.7

IP Total Length MAC Length

Der IP-Header enthält eine Angabe über die Länge des IP-Pakets; diese Angabe umfasst: ■ ■

332

Länge des IP-Headers (normal 20 Oktette) Länge des IP-Pakets (umfasst den IP-Header plus alle nachfolgenden Daten)

>>> NEW TECH

IP: Fehler und Symptome

Addiert man den Umfang des MAC-Frames hinzu (bei dem heute in LANs gebräuchlichen Ethernet-II sind dies 18 Oktette), müsste sich ein Längenwert ergeben, der vom LAN-Analyzer als Länge für den MAC-Frame ausgewiesen wird. Die einzige Ausnahme ergibt sich dann, wenn die IP-Paketlänge kürzer 46 Oktette ist (kann bei Telnet passieren oder leeren TCP-ACK-Paketen), da in diesem Falle einige Stopf-Bytes am Ende des Ethernet-Frames gegeben sind, um die für Ethernet vorgeschriebene Mindest-Frame-Länge von 64 Oktetten zu erreichen. Doch zurück zum eigentlichen Kern: Ein Abgleich zwischen der IP-Paketlänge (mit addierter Ethernet-Header/Trailer-Länge von 18 Oktetten) mit der vom Analyzer ermittelten physikalischen Ethernet Frame Size sollte zu einer Übereinstimmung führen. Gibt es hier Differenzen, wird dies von TraceMagic/ SpiderMagic erkannt und erfasst. Bekannte Gründe sind: ■

■

■

Fehler beim Abspeichern von Trace-Daten in den Formaten anderer Analyzer Es sind mehrere Analyzer bekannt, die beim Abspeichern von Messdaten im sog. Sniffer-Format (.ENC,.TRC,.FDC) Fehler in den Längenangaben erzeugen können. Dies kann zu erheblichen Fehlinterpretationen der Messdaten führen! TraceMagic erkennt dies und weist ggf. darauf hin. Ist ein Ethernet-Frame verkrüppelt (Runt, Collision Frame), kann sich ebenfalls eine Unstimmigkeit bei den Längenwerten ergeben. Dies wäre im weitesten Sinne normal. Werden Ethernet-Frames durch einen Switch verfälscht, können sich ebenfalls diese Unstimmigkeiten ergeben und sie werden ebenfalls erkannt. Ein Beispiel hierfür ist in der Fallstudie zu Voice over IP zu finden.

8.5.8

IP Packet ID = 0

Jedes IP-Paket erhält eine eigene, unverwechselbare Paketnummer. Jeder IPAbsender zählt die IP-Paketnummern (IP Packet ID) von Null oder Eins bis 65.535 (0x0000-0xFFFF). Die meisten IP-Treiber beginnen jeweils bei 1; einige wenige IP-Treiber jedoch beginnen mit der Null. Hierbei handelt es sich nicht um einen Fehler, sondern um ein Ereignis, das ggf. vom IP-Absender gewollt ist. Bestimmte IP-Pakete werden bisweilen gezielt mit Packet-ID = 0 und TTL = 0 gesendet. Die entsprechenden Hinweise von TraceMagic sind keine Fehlerhinweise, sondern haben mehr technischen Charakter.

8.5.9

IP Remote Route Change (IP Packet ID)

Der IP-Treiber eines Absenders zählt alle IP-Pakete laufend durch, in dem der Paketzähler (IP Packet ID) je Paket um den Wert 1 erhöht wird. Da es sich bei dem Paketzähler um einen 16-Bit-Wert handelt (0-65535 bzw. 0x0000-0x FFFF), wird nach Erreichen des Maximalwertes wieder bei 0 bzw. 1 begonnen.

>>> NEW TECH

333

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

Sollten sich Fehler in der Reihenfolge von IP-Paketen ergeben (Paketdreher), so ist dies an den Paketnummern zu erkennen. Fehler in der Reihenfolge sind dann gegeben, ■ ■ ■

wenn ein folgendes IP-Paket eine kleinere ID hat als ein vorangegangenes Paket und wenn dieser Umstand nicht auf den regulären Rücksprung auf Null zurückzuführen ist und wenn dieser Umstand nicht darauf zurückzuführen ist, dass der IP-Absender je IP-Empfänger einen eigenen Zähler für die IP-Paketnummer führt (was in der chronologischen Sicht über alle IP-Dialoge hinweg den Eindruck erwecken kann, die Paketnummern sprängen wild durcheinander – was aber tatsächlich je Dialog nicht der Fall ist).

Ausnahme: Windows9x, Windows Me, Windows NT4 Bei diesen Windows-Versionen wird der 2-Byte-Wert nur im sog. Hi-Byte hochgezählt, was dezimal jeweils einer Erhöhung um den Wert von 255 entspricht. Hierbei handelt es sich um einen Programmierfehler seitens Microsoft. Dieser Fehler ist nicht schädlich. Manchmal ist er lästig, weil er bestimmte Rückschlüsse auf den Datenstrom erschwert. Manchmal ist er hilfreich, weil besagte Windows-Versionen daran gut erkannt werden können. Ausnahme: WindowsXP Bei dieser Windows-Version kann es geschehen, dass die Paketnummer wie folgt gezählt wird: 0x0209, 0x0216, 0x020B oder 0x0309, 0x0316, 0x030B und so weiter. Das heißt immer wenn im Lo-Byte der Wert von 0x0A folgen müsste, wird stattdessen 0x16 eingetragen. Ein Beispiel hierfür ist in der Fallstudie zu Windows-XP Client zu finden. Ausnahme: Paketzähler einzeln je Session Normal ist, dass einige IP-Treiber den IP-Zähler ungeachtet der jeweiligen IP-Dialogbeziehungen (Sessions) erhöht. Normal ist aber auch, dass andere IP-Treiber den IP-Zähler für jede IP-Destination getrennt führen. Dies ist nicht abwegig und auch nicht schädlich. In der Analyse kann dies manchmal hilfreich, manchmal störend sein. Fehler: IP Remote Route Change Wenn IP-Pakete in verkehrter Reihenfolge ankommen, bedeutet dies in der Regel, dass sie im Internet (IntraNet, ExtraNet) verschiedene Wege durchlaufen und sich z.T. gegenseitig überholt haben. Dies bedeutet: Aus der Tatsache einer verkehrten Reihenfolge lässt sich auf das Faktum von Routing-Problemen schließen oder auf falsch eingestelltes Load Balancing. Denn normalerweise wechseln IP-Routen nicht.

334

>>> NEW TECH

IP: Fehler und Symptome

Fehler: IP Remote Route Long Way Siehe Abschnitt 8.5.17 »IP Remote Route Change (TTL)«.

8.5.10 IP Packet ID / Duplicate ID / IP Local Loop Sind vom selben Absender zur (fast) selben Zeit zwei IP-Pakete mit derselben Paket-ID zu sehen, kann das folgende Bewandtnis haben: ■

■

■

■

Paketfragmente Es handelt sich um mehrere Fragmente des vormals selben IP-Pakets. Dies dürfte auf LAN-Leitungen nie zu sehen sein, da es in der Regel die Reaktion von Routern ist, wenn die IP-Pakete für einen bestimmten Router-Link zu groß sind, weil die auf dem Router-Link unterstützte MTU (Maximum Transmission Unit) zu klein ist. IP Local Loop Wird ein IP-Paket von einem Router in dasselbe LAN-Segment zurückgesendet, aus dem es kam, ist die IP-Paketnummer (IP Packet ID) der beiden sichtbaren IP-Pakete identisch: Es ist dasselbe IP-Paket, einmal vor, einmal nach dem Routing-Prozess. In diesem Falle unterscheiden sich die beiden Pakete erstens durch verschiedene TTL-Werte, zweitens durch verschiedene IP-Prüfsummen. IP MAC Multiple Tx Sind die Werte sowohl der IP Packet ID wie auch der TTL identisch, dürften i.d.R. alle anderen Bestandteile des IP-Headers ebenfalls identisch sein. Das würde bedeuten, dass nicht etwa ein IP-Paket durch einen Router ins lokale LAN-Segment zurückgesendet wurde (IP Local Loop, IP Local Routing), sondern dass eine Layer-2-Komponente (Adapter, Switch) den MACFrame irregulär vervielfältigt hätte. Ein Beispiel hierfür ist in der Fallstudie zu Voice over IP geschildert. Dies gilt nicht im Falle von Token-Ring Source-Routing bzw. den ARBs (All Routes Broadcasts). Dies gilt ebenfalls nicht bei IP-Multicasts an IP = 224.0.0.x, da hier verschiedene aufeinander folgende IP-Pakete tatsächlich mit den selben Header-Werten verschickt werden (können), insbesondere mit derselben IP Packet ID. IP Packet ID / Multiple Use Der IP-Treiber des Absenders erhöht zwischen zwei IP-Paketen nicht (wie vorgeschrieben) die IP Packet ID. Dieses Szenario ist extrem selten, ist aber schon beobachtet worden, so bei IP-Paketen, die von den Routern eines allgemein bekannten Herstellers verschickt werden (nicht immer, nicht alle Baureihen, nicht zu allen Anlässen – bobachtet wurde das im Zusammenhant mit Voice over IP-Routern).

>>> NEW TECH

335

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

8.5.11 IP Packet ID / doppelt in verschiedenen Paketen Dieselbe IP Packet ID taucht in verschiedenen Paketen auf. ■

■

Dies wäre normal, wenn der Adressraum der IP Packet ID (0 bis 65.535) erschöpft wäre und wieder bei 0 bzw. 1 begonnen worden wäre, da über die Zeit gesehen eben jede Paketnummer ein weiteres Mal verwendet würde. In diesem Falle aber lägen immerhin tausende von IP-Paketen mit anderen Nummern dazwischen und es wäre einiges an Zeit verstrichen. Dies ist aber nicht normal, wenn dieselbe IP Packet ID bei Paketen auftaucht, die mehr oder weniger unmittelbar aufeinander folgend gesendet werden.

Dieses absolut falsche Verhalten wurde in 2002 häufiger beobachtet. Das auffälligste Beispiel waren Router, die als Voice over IP Endpunkte arbeiteten. Alle VoIP-Pakete hatten die selbe Packet ID – trotzdem lief die VoIP-Kommunikation einwandfrei. Allerdings muss damit gerechnet werden, dass im Falle einer IP-Paket-Fragmentierung zwischen den VoIP-Endpunkten Probleme auftreten können.

8.5.12 IP Fragmented Packets Das Fragmentieren von IP-Paketen soll(te) eigentlich nur zwischen WANRoutern vorkommen. Dieses Verfahren ist in der Regel die Reaktion von WANRoutern, wenn die IP-Pakete für einen bestimmten Router-Link zu groß sind, weil die auf dem Router-Link unterstützte MTU (Maximum Transmission Unit) zu klein ist. Im LAN ist es ein seltenes und zugleich zulässiges Szenario, wenn zwischen zwei Token-Ring-Rechnern ein Transit-LAN mit Ethernet liegt, das mit den Token-Ring-Segmenten links und rechts via Router verbunden ist. Es kann aber auch unbedacht und wenig regulär im LAN zur Fragmentierung von IP-Paketen kommen. Allgemein gilt: Sind im LAN IP-Fragmente zu sehen, liegt meistens ein Fehler vor. ■

■

336

Konfigurationsfehler Router und/oder Endgeräte können falsch eingestellt sein. Applikationsfehler Applikationen können den IP-Treiber zwingen, mit Fragmentierung ab Endgerät (!!) zu arbeiten. Insbesondere bei Microsoft NFS für Windows ist dies bekannt (bis einschließlich WinNT4).

>>> NEW TECH

IP: Fehler und Symptome

8.5.13 IP Time-To-Live (TTL) / Erfassung aller Werte SpiderMagic führt eine Liste aller TTL-Werte, die in den Paketen eines jeden IPAbsenders zu sehen sind. Diese TTL-Liste macht ggf. schnell deutlich, ob bzw. dass es wechselnde und/oder ungünstige Routen durch ein großes Router-Netz gibt. Siehe Abschnitt 8.5.17 »IP Remote Route Change (TTL)«. Im TraceMagic Event-Log wird ebenfalls auf niedrige TTL-Werte aufmerksam gemacht.

8.5.14 IP Time-To-Live / TTL = 0 Der Wert TTL = 0 wird gerne verwendet, wenn ein IP-Paket niemals von einem Router weitergeleitet werden soll. IP-Multicasts an 224.0.0.x haben oft TTL = 0 (oder TTL = 1, TTL = 2). Wenn im Zuge eines Routing-Prozesses der TTL-Wert eines IP-Paketes auf Null fällt, wird das Paket mit dem finalen TTL = 0 verworfen. Ein solches Discarded Packet ist auf der Leitung niemals zu sehen, dafür aber ggf. die ICMPMeldung, die der Router daraufhin an den ursprünglichen Absender des verworfenen IP-Paketes schickt.

8.5.15 IP Local Loop/Both Packets: Before And After Hop Sendet ein IP-Router ein IP-Paket in dasselbe LAN-Segment zurück, aus welchem es kommt, liegt (aus Sicht von Layer 2) ein sog. IP Local Loop vor bzw. ein sog. IP Local Routing. Wenn TraceMagic beide Pakete sieht (zum Router hin, vom Router zurück), wird dies gekennzeichnet als: IP Local Loop / Both Packets: Before and After Hop ■ ■

Dies ist normal, wenn ein Router auf diesem LAN-Interface Multi-Homing, also mehrere verschiedene IP-Subnetze betreibt. Dies ist nicht normal, wenn z.B. durch falsche Einstellungen im Bereich des IP Default Gateway oder in der fehlenden Reaktion von IP-Endgeräten auf Router-Meldungen ICMP:Redirect die IP-Pakete ständig an einen falschen Router geschickt werden. Bei Windows9x und WindowsNT4 (bis SP4) wurde mehrfach beobachtet, dass die Lernfähigkeit der IP-Treiber begrenzt ist, wenn sie von einem Router die Meldung ICMP:Redirect erhalten.

>>> NEW TECH

337

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

8.5.16 IP Local Loop/Single Packet: Only After Hop Sendet ein IP-Router ein IP-Paket in dasselbe LAN-Segment zurück, aus welchem es kommt, liegt (aus Sicht von Layer 2) ein sog. IP Local Loop vor bzw. ein sog. IP Local Routing. Wenn TraceMagic nicht beide Pakete sieht (zum Router hin, vom Router zurück), sondern nur das vom Router weitervermittelte Paket, so wird dies gekennzeichnet als: IP Local Loop / Single Packet: Only After Hop

Dies ergibt sich dann (abhängig vom Messpunkt), ■ ■ ■

wenn es sich um ein Switched LAN handelt, in dem der IP-Absender nicht direkt am Messpunkt zu sehen ist, in dem aber sehr wohl die Weiterleitungen des Routers (die vom Router weiter geleiteten Pakete) zu sehen sind.

Es ist nicht zWindowsgend, dass es sich bei einem solchen Ereignis um einen LocalLoop handelt. Wenn sich jedoch aus anderen Merkmalen ergibt, dass der IP-Absender ■ ■

im selben LAN-Segment (nur jenseits von LAN-Switches) und somit im selben IP-Subnetz

siedelt, so handelt es sich trotz des nur nach dem Router-Hop zu sehenden einen Paket, um einen LocalLoop. Der Nachweis ist somit indirekt. Es handelt sich hierbei i.d.R. um einen normalen Vorgang.

8.5.17 IP Remote Route Change (TTL) Sind vom selben IP-Teilnehmer Pakete mit wechselnden TTL-Werten zu sehen, die sämtlich auf denselben Ausgangswert zurückgehen (255 oder 128 oder 64 etc.), so durchlaufen die IP-Pakete vermutlich verschiedene Routen und erfahren daher verschiedene TTL-Wertminderungen durch die Router. Der TTL-Wert stellt einen Hop Credit dar; aus den ersichtlich abgezählten TTL-Werten ergibt sich indirekt der Hop Count, also die Zahl der bereits übersprungenen Router (Router-Hop). Beispiel: Ein IP-Teilnehmer ist mit Paketen zu sehen, die folgende TTL-Werte enthalten: ■ ■ ■

338

TTL = 124 TTL = 123 TTL = 121

>>> NEW TECH

IP: Fehler und Symptome

Ist das der Fall, so ist davon auszugehen, ■ ■ ■

dass der Ausgangswert TTL = 128 war, dass verschiedene Routen durchlaufen werden, dass die Routen mal 4, mal 5, mal 7 Hop Counts entsprechen.

Das kann im Ergebnis in zweierlei Weise charakterisiert werden: ■ ■

IP Remote Route Change IP Remote Route Long Way

Als IP Remote Route Change wird von TraceMagic der Umstand bezeichnet, dass die IP-Pakete verschiedene Routen nehmen. Als IP Remote Route Long Way wird von TraceMagic der Umstand bezeichnet, dass IP-Pakete längere Wege laufen als nötig. Im gegebenen Beispiel wären die Pakete mit TTL = 121/123 unnötig lange Wege gelaufen, da es mit TTL = 124 ja auch geht (ging). Dieses Szenario ist vom IP Local Loop zu unterscheiden, bei dem ebenfalls wechselnde TTL-Werte zu sehen sind (aber bei identischen Paketen, während bei Remote Route Long Way kein Paket doppelt zu sehen ist).

8.5.18 IP Remote Route Long Way (TTL) Siehe Abschnitt 8.5.17 »IP Remote Route Change (TTL)«.

8.5.19 IP Packet Ping-Pong (TTL) Als TTL Ping-Pong bezeichnet TraceMagic das Hin- und Herpendeln eines IPPaketes zwischen zwei IP-Routern, bis der TTL-Wert auf 0 fällt und das Paket daher verworfen wird – was vom entsprechenden Router mit der Mitteilung gemeldet wird: ICMP: Time Exceeded In Transit/TTL=0

Die Protokoll-Merkmale dieses Ereignisses sind: ■ ■ ■

Das IP-Paket ist mehrfach auf der Leitung. Gleich bleibende IP Packet ID Herabzählende TTL-Werte

Das Paket pendelt wie ein Tischtennisball beim Ping-Pong zwischen den beiden Routern und da der TTL-Wert sich jedes Mal ändert, bezeichnet TraceMagic das Szenario als TTL Ping-Pong (oder IP Packet Ping-Pong).

>>> NEW TECH

339

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

8.5.20 IP Checksum Die IP-Prüfsumme dient messtechnisch als zweiter Hinweis auf die Identität zweier Pakete. Normalerweise reicht das doppelte Vorkommnis der Paketnummer (IP Packet ID), um zwei IP-Pakete als identisch zu ermitteln. Fehler in IP-Prüfsummen sind selten und gehen meistens auf Ethernet-Kollisionen oder Switch-Fehler zurück.

8.5.21 IP Source Address TraceMagic kann bis zu 65.500 IP-Absender mit ihren IP-Adressen und jeweils rund 200 Fehler- und Ereigniszählern überwachen. Dies gilt für die beiden Analyse-Module HostMagic und SpiderMagic. Die Ergebnisse werden in folgenden Formaten ausgegeben: -> -> .TXT -> .HTML ->

■

.DB

■

.CSV

■ ■

TraceStatistics-Datenbank von SpiderMagic Tabellen können z.B. in MS Excel weiterverarbeitet werden. lesbare Berichte, gut geeignet zum Kommentieren Report-Projekte, stark verknüpft, daher gut zugänglich

8.5.22 IP Destination Address Wichtige IP Multicast-Adressen (kein Anspruch auf Vollständigkeit): IP Multicast Address

Bedeutung/Verwendung/Empfänger

224.0.0.0

Base Address (reserved)

224.0.0.1

All Systems on this Subnet

224.0.0.2

All Routers on this Subnet

224.0.0.3

(nicht vergeben/unassigned)

224.0.0.4

DVMRP Routers

224.0.0.5

OSPF-IGP All Routers

224.0.0.6

OSPF-IGP Designated Routers

224.0.0.7

ST Routers

224.0.0.8

ST Hosts

224.0.0.9

RIP2 Routers

224.0.0.10

IGRP Routers

224.0.0.11

Mobile Agents

224.0.0.12

DHCP Server/Relay Agent

224.0.0.13

All PIM Routers

Tabelle 8.2: Tabelle der IP-Multicast-Adressen (Auswahl)

340

>>> NEW TECH

IP: Fehler und Symptome

IP Multicast Address

Bedeutung/Verwendung/Empfänger

224.0.0.14

RSVP-Encapsulation

224.0.0.15

All CBT Routers

224.0.0.16

Designated SBM

224.0.0.17

All SMBs

224.0.0.18

VRRP

224.0.0.19

IP All L1 Iss

224.0.0.20

IP All L2 Iss

224.0.0.21

IP All ISs (Intermediate Systems)

224.0.0.22

IGMP

224.0.0.23

GlobeCast-ID

224.0.0.24

(nicht vergeben/unassigned)

224.0.0.25

Router-To-Switch

224.0.0.26

(nicht vergeben/unassigned)

224.0.0.27

All MPP Hello

224.0.0.28

ETC Control

224.0.0.29

GE-FANUC

224.0.0.30

Indigo-VHDP

224.0.0.31

ShinBroadband

224.0.0.32

Digistar

224.0.0.33

FF-System-Management

224.0.0.34

PT2-Discover

224.0.0.35

DX Cluster

224.0.0.36

DTCP Announcement

224.0.0.37 -

(nicht vergeben/unassigned)

224.0.0.250 224.0.0.251

MDNS

224.0.0.252-

(nicht vergeben/unassigned)

224.0.0.255 224.0.1.39

Cisco RP Announce

224.0.1.40

Cisco RP Discovery

224.0.1.53

Heartbeat

224.0.1.115

Simple Multicast

224.0.1.118

Tivoli Systems

Tabelle 8.2: Tabelle der IP-Multicast-Adressen (Auswahl) (Forts.)

>>> NEW TECH

341

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

8.5.23 IP Option / Header Extension Der IP-Header ist bei IPv4 im Normalfall 20 Oktette lang, dargestellt als Längenangabe 0x05 im ersten Oktett des IP-Headers und ist mit Faktor 4 zu multiplizieren: 5 x 4 = 20 Oktette Der IP-Header kann jedoch über die normalen 20 Oktette hinaus Erweiterungen aufnehmen, die als Options bezeichnet werden. Eine bekannte IP-Option ist das IP Source Routing. Das bekannte TraceRoute arbeitete früher mit der Funktion IP Source Routing. Heute wird TraceRoute in einer Kombination von Ping (das ist: ICMP: Echo Request/Reply) und DNS (Inversiv-Abfragen) durchgeführt, da davon ausgegangen werden kann, dass alle Router ICMP unterstützen, nicht alle jedoch IP Source-Routing.

8.6 TCP: Fehler und Symptome Typische Fehler, aber auch seltene Ereignisse von TCP werden in den folgenden Abschnitten beschrieben, darunter auch solche, die von herkömmlichen Analyzern überhaupt nicht berücksichtigt werden, so beispielsweise TCP-Pakete, die auf MAC/IP-Ebene als Broadcast oder Multicast addressiert sind.

8.6.1

TCP Packet = Broadcast/Multicast

TCP-Pakete dürfen normalerweise nie als Broadcasts/Multicasts auf der Leitung sein. Wann immer dieses der Fall ist, muss geklärt werden, wer in welchem Kommunikationsablauf diese Pakete schickt bzw. welche Komponente ggf. diese Pakete von Unicasts (= Non-Broadcasts/Non-Multicasts) umstempelt bzw. zu Broadcasts/Multicasts verfälscht. Als Broadcast/Multicast in diesem Sinne zählen alle MAC Layer Frames, ■ ■

deren I/G Bit im 1. Oktett der MAC Destination Address auf 1 gesetzt ist (Multicast/Broadcast Bit); deren Token-Ring Source-Routing Header (RIF = Routing Information Field) die Kennung für ARB oder SRB tragen (ARB = All Routes Broadcast, SRB = Single Route Broadcast).

Es wurden in den vergangenen Jahren mehrfach ATM-Backbones beobachtet, die TCP-Pakete im Token-Ring als Token-Ring Source-Route Broadcasts (ARB/ SRB) übertrugen – und zwar sporadisch. Teilweise war dies auf Einstellungen auf den LAN Emulation Broadcast And Unknown Server (LESBUS) zurückzuführen.

342

>>> NEW TECH

TCP: Fehler und Symptome

Das massive Verfälschen von TCP-Paketen zu LAN-Multicasts ist noch im Herbst 2002 vom Verfasser in einer Token-Ring-Umgebung beobachtet worden, mit der Folge, dass Millionen von TCP-Paketen als LAN-Multicasts sämtliche Segmente geflutet haben. Dieser Vorgang ist nicht zu verwechseln mit dem Fluten von Frames, deren MAC Destination Address den Switches jeweils noch unbekannt ist (etwa bei TCP-SYN, also zu Beginn des Verbindungsaufbaus). Bei unbekannten MACAdressen haben Switches die Pflicht, die Frames über alle Ports zu fluten. Hierbei handelt es sich jedoch nicht um Broadcasts/Multicasts im Sinne einer entsprechenden Adressierung in der MAC-Adresse oder im TOK-SR RIF.

8.6.2

TCP Retransmission / ReTx SeqNo = PreTx SeqNo

TCP Retransmission/Same Sequence Number Seen Before ReTx = ReTransmission = Wiederholungsübertragung PreTx = PreTransmission = vormalige Erstübertragung derselben Daten

Diese Variante der TCP Retransmission zeichnet sich durch das folgende Merkmal aus: Die TCP Sequence Number des aktuellen TCP-Pakets ist identisch mit der TCP Sequence Number eines vorherigen TCP-Paketes. Das vorige TCP-Paket ist dadurch als Erstübertagung erkennbar (TCP-PreTx), das aktuelle TCP-Paket als Wiederholungsübertragung (TCP-ReTx). Die Identität der Sendeposition (Sende-Offset) bei ReTx und PreTx, angezeigt durch die jeweilige Offset-Kennung der TCP Sequence Number, ist gängig bei uni-direktionalen Datei-Übertragungen. Anderer Fall: Die Ungleichheit der TCP Sequence Number zwischen ReTx und PreTx ist dagegen eher typisch für bi-direktionale Transaktionsdialoge, Prozessdatenübertragungen, IPC-Dialoge (Inter Process Communication) und dialogorientierte Sitzungen.

8.6.3

TCP Retransmission / ReTx SeqNo PreTx SeqNo

TCP Retransmission/Same Sequence Number Seen Before ReTx = ReTransmission = Wiederholungsübertragung PreTx = PreTransmission = vormalige Erstübertragung derselben Daten

Diese Variante der TCP Retransmission zeichnet sich durch das folgende Merkmal aus: Die TCP Sequence Number des aktuellen TCP-Pakets ist nicht identisch mit der TCP Sequence Number eines vorherigen TCP-Paketes (TCP-PreTx). Das aktuelle TCP-Paket ist als TCP-ReTx erkennbar durch den Umstand,

>>> NEW TECH

343

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

1. dass die aktuelle Sendeposition des aktuellen TCP-Paketes, ausgewiesen durch die TCP Sequence Number, niedriger ist als eine zuvor bereits erreichte Sendeposition (ohne dass etwa eine Veränderung der IP-Pakete in ihrer Sendereihenfolge gegeben wäre, was bei wechselnden IP-Routen der Fall sein kann und nur ein simpler Paketdreher wäre), und 2. dass die Datenmenge, die mit dem aktuellen TCP-Paket gesendet wird, ganz oder teilweise bereits mit einem vorigen TCP-Paket übertragen wurde. Die Ungleichheit der TCP Sequence Number zwischen ReTx und PreTx ist typisch für bi-direktionale Transaktionsdialoge, Prozessdatenübertragungen, IPC-Dialoge (Inter Process Communication) und dialogorientierte Sitzungen. Anderer Fall: Die Identität der Sendeposition bei ReTx und PreTx, angezeigt durch die jeweilige Offset-Kennung der TCP Sequence Number, ist gängig bei uni-direktionalen Datei-Übertragungen.

8.6.4

TCP ReTx / Keep-Alive ReTransmission

TCP: 1 Byte Only = Garbage Byte = Keep Alive Packets

Kommt über längere Zeit kein TCP-ACK der Gegenstelle und tritt daher ein Timer-Ablauf ein (Zeitüberschreitung), so kann ein TCP-Treiber versuchen, die Gegenstelle zur Abgabe eines Lebenszeichens zu bewegen, indem ein wertloses Daten-Byte gesendet wird – schlicht, um nur ein leeres TCP-ACK zurückzuerhalten als Beweis dafür, dass die Gegenstelle noch lebt und die Sitzung aufrecht erhält. Dieses Dummy-Byte wird auch Garbage Byte genannt (Müll-Byte). Die mehrfache Übertragung eines Garbage Bytes an derselben – scheinbaren – Sendeposition (TCP Sequence Number) darf als Zeichen für folgendes Szenario gesehen werden: 1. Die Gegenstelle ist mehrfach nicht erreichbar bzw. dauerhaft inaktiv bzw. die Netzwerk-Verbindung ist dauerhaft gestört. 2. Bei Erreichen der maximalen Anzahl TCP-ReTx (bei MS Windowsdows: 5) wird die TCP-Session mit TCP-RST beendet bzw. abgebrochen. 3. Ein erhöhtes Aufkommen von TCP-RST sowie von Garbage Byte ReTx hat inneren Zusammenhang: Erst ist von der Gegenstelle kein normales TCPACK mehr zu hören, dann meldet sich die Gegenstelle mehrfach nicht auf die Garbage Bytes bzw. Keep Alive Packets und dann wird die Sitzung per TCP-RST-Signal beendet. Die Übertragung von Garbage Bytes ist insbesondere bei einigen Telnet-Varianten üblich.

344

>>> NEW TECH

TCP: Fehler und Symptome

8.6.5

TCP No ReTx / IP Local Loop

TCP Packet Routed Locally

Ist dieselbe TCP Sequence (derselbe TCP-Header) zweimal zu sehen, liegt wahrscheinlich ein IP Local Routing vor. TraceMagic erkennt, dass es sich in diesen Fällen nicht um eine TCP-ReTx handelt, sondern um ein unauffälliges Ereignis.

8.6.6

TCP No ReTx / IP Paketdreher

TCP Sequence Disordered/IP Packet Disordered/IP Packet Sort Error

Eine chronologisch gesehen rückläufige TCP Sequence Number (Sende-Offset) kann auf simple IP-Paketdreher zurückzuführen sein. TraceMagic erkennt, dass es sich in diesen Fällen nicht um eine TCP-ReTx handelt, sondern um ein unauffälliges Ereignis. Eine TCP ReTx ist normalerweise daran zu erkennen, 1. dass eine aktuelle TCP Sequence Number (Sendeposition/Offset) im Wert niedriger ist als eine zuvor bereits erreichte TCP Sequence Number, 2. dass die übertragene TCP-Nutzdatenmenge bereits zuvor einmal gesendet wurde (ganz oder teilweise). Die Bedingung unter (2) ist naturgemäß oft nicht per TCP-Paket nachweisbar, insofern ja die TCP-ReTx ihren Grund in einem Paketverlust haben kann. Dann hätte zwar die Erstübertragung irgendwann einmal stattgefunden, wäre aber nicht positiv durch ein vom Analyzer eingelesenes TCP-Paket nachweisbar. Nur die Wiederholungsübertragung (ReTx) wäre nachweisbar. TCP-Pakete, die in ihrer Reihenfolge verdreht sind, können mit folgendem Szenario beschrieben werden: 1. Die aktuelle TCP Sequence Number ist im Wert kleiner als die des vorangegangenen TCP-Paketes. 2. Die IP Packet ID zeigt, dass es sich sehr wohl um eine durchgängig gesendete TCP-Datenfolge handelt und dass auch die TCP Sequence Number seitens des Absenders korrekt hochgezählt wurde, dass aber die zwei betrachteten TCP-Pakete im Netzwerk ihre Reihenfolge verloren – dergestalt, dass das ursprünglich nachfolgend gesendete Paket vom vorigen Paket überholt wurde. Dies kann Folge verschiedener IP-Routing-Wege sein, aber auch von (fehlerhafter) Prioritäts-Steuerung eines Switches/Routers. In einem solchen Falle sieht es also auf der reinen TCP-Ebene nach einer ReTx aus, aber unter Ansehung der IP-Header ergibt sich kein solches TCP-Ereignis (keine ReTx), sondern ein IP Routing-Ereignis (wechselnde IP-Wege: IP Route Route Change).

>>> NEW TECH

345

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

8.6.7

TCP No ReTx / Header Duplicate

IP und TCP Header Duplicate/Possible MAC Multiple Tx

Siehe Abschnitt 8.5.2 »IP Packet: MAC Multiple Tx/Duplicate IP Header«.

8.6.8

TCP Missing Sequence

Possibly Lost Packet :: Possibly Analyzer Buffer Overflow

Die TCP Sequence Number (SeqNo) gibt je TCP-Paket die seitens des jeweiligen Absenders erreichte Sendeposition an (bezogen auf die zu übertragenden Nutzdaten); der Empfänger bestätigt den Erhalt mit der TCP Acknowledge Number (AckNo). Beispiel: Sendet ein TCP-Teilnehmer ab SeqNo = 100200 die Nutzdatenmenge von 55 Bytes, so bestätigt dies der Empfänger mit der AckNo = 100256, was bedeutet: »Empfangen bis 100255; bitte weitersenden ab nächstem Start-Offset = 100256.« Die nächste Übertragung fände dann statt mit SeqNo = 100256. Eine TCP Missing Sequence liegt dann vor, wenn in den aufgezeichneten TCP-Paketen in der Abfolge der Sequenznummern eine Lücke klafft. Dies kann verschiedene Gründe haben: 1. Der Absender hat die im Trace fehlende TCP Sequence (die Datenteilmenge) gar nicht gesendet. Dies ist theoretisch unmöglich und kommt praktisch extrem selten vor (ggf. physikalische Defekte). 2. Der Absender hat die im Trace fehlende TCP Sequence zwar gesendet, aber sie ging während der Übertragung im Netzwerk verloren: – Bitfehler (Leitungsfehler) – Buffer Overflow von Switch/Router – Routing-Fehler (irgendwann TTL = 0) 3. Der Absender hat die im Trace fehlende TCP Sequence zwar gesendet, das entsprechende TCP-Paket war auch am Messpunkt auf der Leitung, aber der Analyzer oder der Mirror-Port hatte Buffer Overflow bzw. war überlastet und konnte daher das Paket nicht aufnehmen. Welche Variante im Einzelfall vorliegt, ergibt sich nur aus dem Gesamtbild der Messdaten.

346

>>> NEW TECH

TCP: Fehler und Symptome

8.6.9

TCP Flag(s) = SYN, ACK, PSH, URG, FIN, RST

TraceMagic wertet die Sitzungs- und Datenfluss-Kommandos von TCP vollständig aus. Diese sind: ■ ■ ■ ■ ■ ■

SYN ACK PSH URG FIN RST

= = = = = =

Synchronize Sequence Numbers Acknowledge Push Urgent Pointer Final Reset

Eine genaue Darstellung ist in der Erstausgabe des Networker’s Guide (April 2000, siehe CD-ROM) nachzulesen. Die Kenntnis dieser TCP-Flags wird an dieser Stelle vorausgesetzt.

8.6.10 TCP Flag = RST/Abbruch TCP-Datenverbindungen (Sessions) werden unter normalen Umständen seitens der Sitzungspartner mit dem Kommando (Flag) TCP-FIN (Final) beendet: Der Datengeber (Server) sendet nach Übertragung sämtlicher geforderter Bytes das FIN-Flag; der Datenempfänger (Client) bestätigt dies mit FIN-ACK, sofern es sich um eine Datei-Übertragung handelte. Bei Prozessdatenübertragungen (IPC, Inter Process Communication), zumal solchen, die bidirektional arbeiten, kann der Empfänger der TCP-FIN-Meldung widersprechen und die Fortsetzung der Sitzung veranlassen. Das Senden von TCP-RST spricht in aller Regel für ein unerwartetes Sitzungsende. Gängige Ursachen können sein: 1. Timer-Ablauf wegen fehlender Quittungen der Gegenstelle, etwa wegen Verlusts der Übertragungswege (Router-Ausfall, Leitungsausfall). 2. Spontane, interne Fehlerbedingung des TCP-RST sendenden Teilnehmers. Unter günstigsten Bedingungen kann innerhalb kurzer Zeit nach dem TCP-RST die Session wieder aufgebaut und fortgesetzt werden; hierbei würde sogar an derselben Sendeposition (TCP Sequence Number) weitergemacht. Dieses Szenario wäre zwar regulär, ist in der Praxis aber (viel zu) selten zu beobachten. In jedem Falle müssen TCP-RST-Ereignisse nachvollzogen werden, wenn sie nicht im Zusammenhang mit WWW-Zugriffen stehen. Anders gesagt: Bei Internetzugriffen sind TCP-RST-Ereignisse gang und gäbe. In diesem Falle läuft das Szenario wie folgt ab: Der Weberver sollte nach Übertragung sämtlicher HTTP-Daten (oder Grafikdaten) mit TCP-FIN das Ende der Übertragung (sowie deren Vollständigkeit) anzeigen – tut er aber (oft) nicht. >>> NEW TECH

347

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

Der Client wartet darauf geduldig, bis der entsprechende Timer abgelaufen ist, der das Abwarten eines TCP-ACK oder eines TCP-FIN seitens der Gegenstelle vorschreibt. Während dieser Zeit erlebt der Anwender, dass der Webbrowser vermeintlich noch Aktivität anzeigt (z.B. pendelnder Laufbalken in der Statuszeile unten oder ähnlich), obwohl gleichzeitig längst gemeldet wurde: 100% geladen. Der Anwender neigt dann zu der Aussage: »Das Netz ist wieder langsam!« Tatsächlich wartet der TCP-Treiber bzgl. des aktiven TCP-Ports auf TCP-ACK bzw. TCP-FIN. Erst nach Ablauf des Timers sendet dann der Client ein TCP-RST an den Webserver – der dies meistens völlig ignoriert und nicht beantwortet. Webserver sind eben viel beschäftigt und befassen sich nicht mit jedem Kleinkram. ... Unterbricht der Anwender die Wartezeit mit Betätigen des Abbruch-Buttons, so wird der Timer abgebrochen und es wird unmittelbar bzw. sofort ein TCP-RST gesendet.

8.6.11 TCP Flag = SYN/ReTx Possibly Error/TCP Session Request Not Acknowledged And Retransmitted

Die Anfrage bzw. Aufforderung zum Sitzungsaufbau mittels TCP-SYN sollte vom Empfänger sofort mit TCP-SYN-ACK bestätigt werden (was der Initiator seinerseits mit TCP-ACK zu beantworten hat). Verschiedene Ursachen können bewirken, dass der Initiator mehrfach TCP-SYN in Wiederholung (ReTx = ReTransmission) sendet: 1. Der Empfänger ist nicht eingeschaltet. Die TCP-SYN-ReTx ist normal und kein Zeichen für eine Störung. Allenfalls muss gefragt werden, warum eine Sitzung mit einem nicht erreichbaren Rechner begehrt wird. 2. Die Verbindung zum Empfänger, die eben noch vorhanden war, ist zwischen zwei Sitzungen abgebrochen. Der Initiator weiß noch nicht, dass die Verbindung physikalisch nicht mehr gegeben ist und versucht daher ganz normal, eine Sitzung aufzubauen. Der Initiator wiederholt ggf. das TCP-SYN. 3. Der Empfänger des TCP-SYN ist überlastet. Ggf. sendet der Empfänger in Reaktion ein TCP-RST zurück. Der Initiator wiederholt ggf. das TCP-SYN. 4. Der Empfänger darf den angefragten TCP-Port oder den IP-Absender nicht bedienen. Für diesen Fall könnte der Empfänger ggf. mit TCP-RST reagieren. Der Initiator wiederholt ggf. das TCP-SYN. 5. Eine Firewall blockt das TCP-SYN ab. Ggf. beantwortet die Firewall das TCPSYN mit TCP-RST. Der Initiator wiederholt ggf. das TCP-SYN.

348

>>> NEW TECH

TCP: Fehler und Symptome

6. Die Laufzeit der TCP-Pakete zwischen Initiator und Empfänger ist extrem lang. Ggf. überschneiden sich das TCP-SYN-ACK des Empfängers und die (mehr oder weniger) gleichzeitig gesendete TCP-SYN-ReTx des Initiators. 7. Es liegt seitens des Initiators ein sog. TCP SYN Flooding vor, das Überfluten des Empfängers mit TCP-SYN-Anfragen. Dies ist in aller Regel, sofern gegeben, auf Computer-Viren bzw. Hacker-Angriffe zurückzuführen. Ältere WindowsNT4-Versionen reagierten auf TCP SYN Flooding noch mit gelegentlichem Absturz bzw. mit völliger Erschöpfung ihrer SystemRessourcen. Seither kann mit Registry-Einstellungen der TCP-Treiber veranlasst werden, pro Zeiteinheit nur eine begrenzte Anzahl von TCP-SYN-Anfragen zu bearbeiten bzw. nur eine begrenzte Menge von System-Ressourcen zu binden. Aktuell in 2001 und 2002: Der Virus Code Red blockierte bei angegriffenen TCP-Endgeräten sowie Management-Ports von Switches und Routern massiv System-Ressourcen durch TCP SYN Flooding gezielt auf den TCP HTTP-Port.

8.6.12 TCP Flag = FIN/ReTx Possibly Error/TCP Final Request Not Acknowledged And Retransmitted

Das wiederholte Senden von TCP-FIN-Meldungen (Final = Ende der Übertragung der angeforderten Datenmenge) beruht in aller Regel auf dem Ausbleiben der TCP-FIN-ACK-Bestätigungen der Gegenstelle. Bei WWW-Servern ist dies durchaus üblich, insofern erfahrungsgemäß viele Webserver den Umgang mit TCP-FIN und TCP-RST nicht sonderlich genau nehmen. TCP-FIN wird zum regulären Abbau einer TCP-Sitzung ausgetauscht. TCP-RST wird bei außerplanmäßigen Sitzungsabbrüchen gesendet.

8.6.13 TCP Flag = RST/ReTx Possibly Error/TCP Reset Message Not Acknowledged And Retransmitted

Die Mitteilung zur außerplanmäßigen Sitzungsbeendigung mittels TCP-RST beruht möglicherweise auf ernst zu nehmenden Störungen (WWW-Zugriffe via HTTP i.d.R. ausgenommen). Der Empfänger einer TCP-RST-Meldung sollte den Erhalt bestätigen; geschieht dies nicht, könnte eine TCP-RST-ReTx die Folge sein. Vermutlich erfolgt die ReTx (ReTransmission) der TCP-RST-Meldung, weil die Netzwerk-Verbindung unterbrochen ist und somit die Empfangsquittung den Absender des TCP-RST nicht erreichen kann.

>>> NEW TECH

349

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

Je nach Ursache für das Senden der TCP-RST-Meldung ist damit zu rechnen, dass es trotz fehlender Quittung der Gegenstelle keine TCP-RST-ReTx geben wird, insofern eine interne Störung des meldenden Rechners jedes weitere Senden von TCP-Paketen verhindert bzw. verbietet. Ein Sonderfall sind TCP-RST-Meldungen im Zusammenhang mit WWW-Zugriffen. Bei Internetzugriffen sind TCP-RST-Ereignisse gang und gäbe. Siehe Abschnitt 8.6.10 »TCP Flag = RST/Abbruch«.

8.6.14 TCP Window Size Low TCP Window Size Low/WinSize < 1000-100-10/WinSize = 0 (Zero)

Jeder TCP-Empfänger gibt der Gegenstelle die Größe des reservierten (bereitgestellten) Eingangs-Puffers bekannt. Dies verfolgt verschiedene Zwecke: 1. Es wird der Gegenstelle eine Abnahmegarantie für die entsprechende Datenmenge gegeben (Durchsatz). Die Gegenstelle kann die annoncierte Datenmenge senden, ohne auf Einzelquittungen für Teilmengen warten zu müssen. Dieser Effekt ist gezielt erwünscht, insbesondere auf WAN-Leitungen: Die Verminderung der TCP-ACKs (Quittungen) entlastet die Leitung (wenn auch nur geringfügig). Das Nicht-Abwarten von TCP-ACKs innerhalb der vom Empfänger frei gegebenen Datenmenge hat seitens des Absenders zur Folge, dass diese Datenmenge schneller auf die Leitung gebracht werden kann, da eben nicht nach je einem (einzelnen) Paket die entsprechende Quittung abgewartet werden müsste (was als Ping-Pong-Verfahren bzw. Einzelquittungs-Verkehr bekannt und strikt zu vermeiden ist). 2. Der Empfänger, der die TCP Window Size der Gegenstelle (dem Datensender) bekannt gibt, schützt sich vor Puffer-Überlauf (Buffer Overflow), indem die im nächsten Sendestoß (Burst) zu erwartende Datenmenge von vornherein begrenzt ist. Die TCP Window Size hat per Vorgabe die Größe von 6 x MSS (Maximum Segment Size). Beispiel: TCP Default WinSize auf Ethernet = 8760 (6 x 1460 = 8760).

Dass die TCP Window Size eines TCP-Empfängers unter diesen Default-Wert fällt, kann jederzeit sein, kommt auch vor, sollte aber weder über längere Zeit noch (im Wert) erheblich gegeben sein. TraceMagic nimmt als ersten kritischen Wert eine WinSize kleiner 1.000 Bytes an. Dieser Schwellenwert ist letztlich willkürlich gewählt und entspricht langjähriger Erfahrung.

350

>>> NEW TECH

TCP: Fehler und Symptome

Brisant wird es, wenn die WinSize kleiner 100 Bytes ist. Endgültig nachprüfenswert ist eine WinSize von 0 (Zero). WinSize = 512/536/576 Octets Eine WinSize von 512 oder 536 oder 576 Oktetten könnte (muss aber nicht) ein Zeichen dafür sein, dass der TCP-Empfänger die Gegenstelle zwingen will, niemals TCP-Pakete zu senden, die größer sind als 512 plus 20 plus 20 Oktette sind: 512 Octets Nutzdaten 20 Octets IP Header 20 Octets TCP Header --------------------------------------552 Octets IP Total Length

Als kleinste von allen IP-Routern zu unterstützende TCP-MSS gilt die Datenmenge von MSS = 536 Oktetten; das ergibt eine IP Total Length = 536 plus 20 plus 20 = 576 Oktette. Die Verwendung dieser geringen WinSize-Werte tritt ggf. dann auf, wenn der TCP-Treiber davon ausgeht, dass es eine IP-Transitstrecke gibt, die nur die kleinstmögliche IP-Paketgröße von MMS = 536 Oktetten unterstützt. Normalerweise beschränkt sich der TCP-Absender selber auf entsprechend kleine Pakete; über eine entsprechend kleine WinSize aber kann die Gegenstelle die gebotene kleine Paketgröße ebenfalls nicht mehr überschreiten. MS Windows Registry Keys HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\.. ..\EnableDeadGWDetect = Dead Gateway Detection ..\EnablePMTUBHDetect = MTU Black Hole Detection ..\EnablePMTUDiscovery = MTU Discovery

Window Size/Frozen Window Von einem eingefrorenen Puffer-Fenster spricht man, wenn die annoncierte TCP Window Size über längere Zeit gleich bleibt (genauer: über sechs TCPPakete hinweg). Dies war in den 80-er Jahren das Zeichen für einen ggf. gestörten TCP-Treiber. Heutzutage kommt dieses Phänomen reichlich vor, da die Rechner inzwischen so viel Hauptspeicher haben, dass sie zum Teil allen TCP-Sessions die maximale TCP Window Size permanent zur Verfügung stellen können. Das dürfte dann nicht als Frozen Window missverstanden werden! Window Size Zero Fällt die TCP Window Size eines TCP-Empfängers auf Null (Zero), kann dies bedenklich sein, muss aber nicht:

>>> NEW TECH

351

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

■

■

Netzwerk-Drucker bremsen den Datenempfang regelmäßig, wenn ihr Eingangs-Puffer voll ist, mit WinSize = 0, da sie für Druckvorbereitung (Rendering) und Druckausgabe Zeit brauchen. Das Senden von TCP-ACK mit WinSize = 0 signalisiert der Gegenstelle, dass der Drucker zwar aktiv ist, zurzeit aber keine weiteren Daten annehmen kann. PC-Clients und PC-Server sollten für gewöhnlich nicht mit WinSize = 0 arbeiten. Geschieht dies doch, sollte dies überprüft werden, da allgemein mit Fehlern und/oder Überlastung zu rechnen ist.

8.6.15 TCP MSS Low TCP Maximum Segment Size Low/MSS < 1460-1400-1000-100-10/MSS = 0 MSS = Maximum Segment Size MTU = Maximum Transmission Unit

Die TCP Maximum Segment Size beschreibt die maximale Nutzdatengröße je einzelnem TCP-Paket in Anlehnung an die lokale MTU (Ethernet MTU = 1.500 Oktette). Beispiel: 1500 Octets MTU / Ethernet ./. 20 Octets IP Header ./. 20 Octets TCP Header ----------------------------------------1460 Octets MSS / Ethernet

Für das Zustandekommen des MSS-Wertes gilt: ■ ■ ■

Die MSS wird zu Beginn der TCP-Session mit TCP-SYN ausgehandelt. Beide TCP-Partner teilen sich ihre jeweils lokal bedingte MSS mit. Der niedrigste Wert ist für beide verbindlich.

Die Verwendung der jeweils niedrigsten MSS schützt vor Fragmentierung der IP-Pakete in den LANs der beiden Teilnehmer: Es könnte z.B. sonst sein, dass IP-Pakete, die zunächst in 4.096 Oktette großen Token-Ring-Frames gesendet werden, in einem Ethernet-LAN vom letzten Router dem IP-Host gegenüber fragmentiert werden müssen. Dies soll strikt verhindert werden: Es ist fehleranfällig, kostet Performance und nicht alle IP-Rechner unterstützen das Fragmentieren/Defragmentieren von IPPaketen (MS-DOS mit TCP/IP-Treibern). Das Aushandeln der MSS schützt jedoch nicht davor, dass eine zufällige IPTransitstrecke in ihrer MTU kleiner liegt, als es den MTUs der LANs entspricht, in denen die TCP-Partner siedeln.

352

>>> NEW TECH

TCP: Fehler und Symptome

Sind IP-Pakete zu groß für eine IP-Transitstrecke, würde der Router, der dies bemerkt, Meldungen an die jeweiligen Absender der zu großen IP-Pakete senden: ICMP: Fragmentation Needed/Supported Packet Size

Diese ICMP-Meldungen werden gesendet, sofern eine von zwei Bedingungen gegeben ist: 1. Der Absender hat das Fragmentieren von IP-Paketen über das Don’t Fragment-Bit (DF) verboten. 2. Der Absender hat zwar das Fragmentieren erlaubt (May Fragment), aber der Router ist so eingestellt, dass keine IP-Fragmentierung vorgenommen wird. Nun können in diesem Falle verschiedene Fehler-Szenarien eintreten: Der betroffene IP-Absender »lernt« nicht aus den ICMP-Meldungen des Routers; seine IP-Pakete werden von diesem Router dauerhaft verworfen. ■ Der Router, der die zu großen IP-Pakete verwirft, gibt gar keine ICMP-Meldungen zurück. Solche Router werden Black Hole Router genannt (Schwarzes Loch). ■ Die Tatsache, dass eine IP-Transitleitung eine zu geringe MTU bietet, ist darauf zurückzuführen, dass es sich um eine Ausweichstrecke handelt, die nach einer Netzwerk-Störung aktiviert wurde (und die sonst passiv bzw. ungenutzt ist). Weil diese Ersatzleitung lange nicht verwendet wurde, wurde die MTU nicht kontrolliert bzw. angepasst. Die Netzwerk-Störung nun, die zur Umschaltung führte (bzw. zur Wahl des Ersatzweges), führt zum Verlust der ICMP-Meldungen. In jedem dieser Fälle gilt: Der IP-Absender, dessen IP-Pakete wegen zu geringer MTU der Transitstrecke verworfen werden, erkennt das Unglück auf der Ebene des IP-Treibers nicht, denn der IP-Treiber hat nur über ICMP-Meldungen die Chance, das Szenario zu erkennen und sich darauf einzustellen. ■

In diesem Falle (des Nicht-Erkennens durch den IP-Treiber) greift ggf. der TCPTreiber ein: Erkennt der TCP-Treiber, dass es zu viele TCP-ReTx (ReTransmissions) zu einer bestimmten IP-Destination gibt, geht er davon aus, dass der bisherige IP-Leitweg (IP Route) wegen einer MTU-Problematik und/oder eines Black Hole-Routers ungünstig ist. Der TCP-Treiber wird bei einem solchen Szenario die MSS nach und nach vermindern, bis (hoffentlich) endlich der TCP-Dialog wieder arbeitet bzw. bis die Gegenstelle wieder antwortet. Wird keine Wiederbelebung des TCP-Dialoges über verminderte MSS erreicht oder ist diese Therapie ungenügend, so kann der TCP-Treiber den IP-Treiber veranlassen, einen anderen IP-Leitweg zu wählen (sofern Alternativen vorhanden sind).

>>> NEW TECH

353

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

Problem: Der TCP-Treiber von Windows NT4, Windows 2000K und Windows XP hat zwar die notwendigen Fähigkeiten – aber nur, wenn manuell die entsprechenden Registry-Schalter gesetzt werden! MSS = 576 Oktette Eine MSS = 576 könnte (muss aber nicht) ein Zeichen dafür sein, dass der TCPEmpfänger die Gegenstelle zwingen will, niemals TCP-Pakete zu senden, die größer sind als die Mindestgröße von IP-Paketen, die von allen IP-Routern unterstützt werden muss. Als kleinste, von allen IP-Routern zu unterstützende TCP-MSS gilt die Datenmenge von MSS = 536 Oktetten, das ergibt eine IP Total Length = 536 plus 20 plus 20 = 576 Oktette. Die Verwendung dieses geringen MSS-Wertes ist ggf. dann der Fall, wenn der TCP-Treiber davon ausgeht, dass es eine IP-Transitstrecke gibt, die nur die kleinstmögliche IP-Paketgröße von MMS = 536 Oktetten unterstützt. Normalerweise beschränkt sich der TCP-Absender selber auf entsprechend kleine Pakete; über eine entsprechend klein angegebene WinSize aber kann die Gegenstelle gezwungen werden, ebenfalls mit kleinstmöglichen Paketen zu senden. MS Windows Registry Keys HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\.. ..\EnableDeadGWDetect = Dead Gateway Detection ..\EnablePMTUBHDetect = MTU Black Hole Detection ..\EnablePMTUDiscovery = MTU Discovery

Ungewöhnlich kleine MSS Wird bereits beim Session-Handshake (TCP-SYN) eine deutlich kleine MSS angegeben, könnte dies verschiedene Gründe haben: ■ ■

Wie oben beschrieben: Der TCP-Treiber weiß, dass es IP-Transitstrecken gibt, die keine größeren IP-Pakete zulassen. Die Applikation (die hinter dem angegebenen TCP-Port arbeitet) lässt keine größeren Dateneinheiten zu; hierbei würde es sich eher um alte Anwendungen handeln, vielleicht um Datenbanken (Datensatzgrößen) oder transaktionsbezogene Anwendungen. Dieses Szenario darf als eher abwegig angesehen werden.

8.7 UDP: Name Services Da UDP verbindungslos arbeitet, ist hier wenig zu tun und wenig zu sagen. Selten sind Fehler wirklich in UDP festzustellen; in aller Regel betreffen Fehler die darüber arbeitende Applikation.

354

>>> NEW TECH

UDP: Name Services

8.7.1

UDP Port 53/DNS

UDP Port 53/DNS: Domain Name Service

Fehler im DNS können äußerst gefährlich werden. Zu solchen Fehlern gehören: ■

■

■

Dateinamen werden per DNS gesucht, z.B. JAHRESBILANZ.XLS. Microsoft DNS-Server (Windows NT4) scheuen sich ggf. nicht, solche DNS-Requests ins Internet weiterzusenden. Die sichtlich unsinnigen DateiAbfragen entstehen durch Windows-Clients, die eine gewünschte Datei auf den verfügbaren Servern nicht gefunden haben. Dieses Verhalten wurde durch Synapse:Networks bzw. vom Verfasser mehrfach seit dem Jahre 2000 beobachtet, der unmittelbare Auslöser konnte leider nicht ermittelt werden. So wurde z.B. kein Zusammenhang etwa zu Service-Packs oder Applikationen greifbar (was nicht bedeuten soll, dass es solche Zusammenhänge nicht etwa geben könnte). Timeouts bei DNS-Clients und DNS-Servern sind dann nicht selten. DNS Namens-Mutationen Wenn ein Windows DNS-Client eine gewünschte Auflösung nicht erhalten hat, etwa zu miraculix.gallier.fr, kann er auf folgende Idee kommen: Der Name miraculix.gallier.fr könnte ein alter NetBIOS-Name sein, der jüngst ins DNS übernommen wurde. Für diesen Fall wäre wahrscheinlich anzunehmen, dass dem vormaligen einfachen NetBIOS-Namen der lokale DNS-Domain-Suffix angehängt wurde. Lautet dieser Domain-Suffix beispielsweise goten.de, so wird der DNS-Request in der folgenden Mutation erneut versucht: miraculix.gallier.fr.goten.de. Sollte der Client zudem noch die Domain roma.it kennen, könnten die weiteren DNS-Requests miraculix.gallier.fr.roma.it der auch (der Phantasie sind keine Grenzen gesetzt!) miraculix.gallier.fr.goten.de.roma.it folgen. Dass es sich bei miraculix.gallier.fr nicht um einen NetBIOS-Namen handeln kann, da er länger als 16 Zeichen ist und auch sonst alle Merkmale eines DNS-Namens aufweist (Top Level Domain!), kann Windows-Clients nicht beirren. Besonders übel wird es dann, wenn solcherlei DNS-Requests auch noch ins Internet weitergereicht werden – was Mircosoft DNS-Server (Windows NT4) gerne tun. Timeouts bei DNS-Client und DNS-Server sind dann nicht selten. Je nach Einstellung der Windows-Clients werden NetBIOS-Namen, die über WINS nicht aufgelöst werden konnten, via DNS gesucht. Hier ist in jedem Einzelfall zu prüfen, ob das gewollt ist (oder nicht) und ob es wirkungsvoll arbeitet.

>>> NEW TECH

355

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

8.7.2

UDP Port 137/WINS

UDP Port 137/WINS: Windows Internet Name Service

WINS-Requests als MAC/IP-Broadcasts sind die zweitbeste Wahl. Nach Möglichkeit sollten WINS-Requests an die IP-Adresse des WINS-Servers gerichtet werden (sofern es sich nicht um NBSTAT-Anfragen handelt, die zu Recht unmittelbar an einen IP-NetBIOS-Host bzw. NetBT-Host gerichtet sind). Mögliche Gründe für WINS Requests per Broadcast sind: ■

■

Der WINS-Knotentyp (WINS Node Type) ist auf 1 = Broadcast Node eingestellt. Diese Variante kann in wenigen Fällen Sinn ergeben, sollte aber allgemein vermieden werden. In den meisten Fällen ist der Knotentyp 8 (Hybrid Node) angemessen: Erst wird der WINS-Server angesprochen, danach (bei Misserfolg) wird der Request via Broadcast versendet. Der WINS-Client würde zwar gerne den WINS-Server ansprechen, kennt aber die IP-Adresse des WINS-Servers nicht. Mögliche Gründe: – Der DHCP-Server gibt keine oder eine falsche IP-Adresse für den WINSServer aus. – Die korrekte Angabe des DHCP-Servers bleibt wirkungslos, weil der DHCP-Client mit einer festen Vorgabe arbeitet, die in seiner WindowsRegistry hinterlegt ist (nur MS Windows Rechner). – Der WINS-Server ist nicht erreichbar: Er ist abgeschaltet, die RoutingVerbindung zum WINS-Server arbeitet nicht, der WINS-Client bedient seinerseits das IP-Routing nicht richtig (z.B. falsche IP Subnet Mask), der WINS-Server antwortet zwar, aber ohne die erhoffte Namens- und Adressauflösung (WINS-Server gibt Error-Code zurück).

■

356

Im Falle vermehrter Error-Code-Rückgaben des WINS-Servers kann die Folge sein, dass der WINS-Client den WINS-Server nicht mehr als vertrauenswürdig ansieht. Der WINS-Client wird ggf. auf diese Einschätzung (die sich schlicht aus der Erfolgs- bzw. Misserfolgsstatistik ergibt) mit der veränderten Arbeitsweise antworten, dass nunmehr vermehrt über UDP-Port 138 bzw. über NetBIOS-Broadcasts gearbeitet wird.

>>> NEW TECH

UDP: Name Services

8.7.3

UDP Port 138/NetBIOS Datagram

UDP Port 138/NetBIOS Datagram/SMB Mailslot

NetBIOS-Broadcasts z.B. mit der Funktion SMB-BROWSE werden von WindowsClients dann gerne ersatzweise verwendet, ■ ■ ■

wenn der WINS-Dienst grundsätzlich nicht gegeben ist, wenn der WINS-Server nicht erreichbar ist, wenn der WINS-Server wegen ständiger Erfolglosigkeit nicht mehr als vertrauenswürdig angesehen wird.

In einem Windows-Netzwerk, in welchem der WINS-Dienst vollständig arbeitet (alle Clients nutzen den WINS-Server; der WINS-Server beantwortet alle Anfragen mit der gewünschten Auflösung), sind erfahrungsgemäß nicht viele UDP-138-Rundrufe vorhanden. Eine Rolle spielt dabei jedoch auch, ob der Computersuchdienst (Browser Service) auf den Windows-Clients aktiviert ist (oder eben nicht). Realistisch ist, dass in einem gut gepflegten Windows-Netzwerk, in dem WINS gut arbeitet, nur geringe Mengen von UDP-138-Broadcasts vorhanden sind. Sind viele oder die meisten Windows-Clients in den Messdaten mit UDP-138Rundrufen via Broadcasts zur Suche anderer Rechner vertreten (SMB-BROWSE), so kann dies (fast) immer als sicheres Anzeichen dafür angesehen werden, dass der WINS-Dienst nicht zuverlässig bzw. nicht hinreichend erfolgreich arbeitet. Es kann immer wieder geschehen, dass NetBIOS-Namen unerwünscht gesucht werden, da ständig neue NetBIOS-Namen z.B. über die Laptops externer Dienstleister eingeschleppt werden; oder ungültige NetBIOS-Namen entstehen dadurch, dass alte Namen außer Betrieb genommen werden (eine Domain wird abgeschafft etc.). Da sich die Windows-Clients jedoch an alte Namen »erinnern« und weiter nach ihnen suchen, entstehen mit der Außerdienststellung von Namen NetBIOS-Leichen oder Phantom-Namen, die den Anteil der nicht verifizierbaren NetBIOS-Namen erhöhen – und damit die Wahrscheinlichkeit, dass WINSClients den WINS-Server als unzuverlässig ansehen. Dem kann und muss mit folgender Maßnahme begegnet werden: 1. Mit TraceMagic -> HostMagic -> SingleHosts regelmäßig die Tabelle der Namensdienste erstellen 2. Alle NetBIOS-Namen, die als nicht verifizierbar erkennbar sind, manuell im WINS-Server hinterlegen. Diese Namen werden sämtlich mit derselben IPAdresse versehen (Dummy), diese IP-Adresse darf sonst nicht verwendet werden (sie muss also für diesen Zweck reserviert sein).

>>> NEW TECH

357

Kapitel 8 • OSI-Schichten 3 und 4: TCP/IP

Abbildung 8.1: TraceMagic/HostMagic/SingleHosts: Auswertung der Name-Service-Dialoge (hier: WINS, NetBIOS)

358

>>> NEW TECH

Kapitel 9 OSI-Schichten 5 und 7: Namensdienste Dieses Kapitel wird einige der Rätsel lösen, die sich um das »ceterum censeo« der Anwender ranken: »Das Netzwerk ist langsam! Aber ... wir haben doch Gigabit!?« Ceterum Censeo: Cato der Ältere hielt vor dem römischen Senat ständig flammende Reden, die er stets und ständig beschloss mit dem Credo: »Ceterum censeo, Carthaginem esse delendam!«, was heißt: »Und im übrigen glaube ich, dass Karthago zerstört werden muss!« Die Penetranz dieser steten Wiederholung begründet bis heute die stehende Redensart, dass das unablässige Vorbringen derselben Meinung das »ceterum censeo« eines Menschen bilde. Und so steckt in jedem PC-Anwender heute ein kleiner Cato ... eine Behauptung wird auch durch ihre Wiederholung nicht wahr[er]. Es wird davon ausgegangen, dass der geschätzte Leser die wichtigsten Mechanismen der Namensdienste (Name Services) kennt, sodass wir uns hier gegenseitig ersparen können, die Grundfunktion beispielsweise eines WINS-Servers zu erklären. Wer hier noch Lücken hat, möge die entsprechenden Stellen im Networker’s Guide nachlesen; der Text ist auf der beiliegenden CD-ROM im PDF-Format vollständig mitgeliefert. Die folgenden Beispiele dienen dazu, Phänomene zu zeigen, die es theoretisch niemals geben dürfte – und die man getrost einordnen könnte als »Pferde, die vor der Apotheke kotzen«. Es ist wichtig, dass die übelsten Entgleisungen der verschiedensten Protokolltreiber eines Windows-Clients verstanden werden, um nachvollziehbar zu machen, warum Anwender so gerne sagen: »Das Netzwerk ist langsam.« Denn in vielen Fällen sind es nicht etwa die Switches oder Glasfaserkabel, die bei Gigabit-High-Speed die Wartezeiten verursachen – sondern es sind Namensdienste, die durchdrehen bzw. durch Außeneinflüsse in den Wahnsinn getrieben werden. Microsoft hat aus guten Gründen versucht, das Betriebssystem Windows möglichst fehlertolerant zu gestalten. Teil dieser Vorgehensweise ist, dass bei erfolglosen Funktionsaufrufen geprüft wird, ob andere Funktionen ersatzweise zum Erfolg führen könnten. Das normale Erscheinungsbild dieser Strategie ist, dass Namens- und Adressauflösungen im Zweifel über alle Protokollstapel betrie-

>>> NEW TECH

359

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

ben werden, die dem Rechner zur Verfügung stehen: Ist also erst einmal die Auflösung via WINS fehlgeschlagen, wird sie per DNS versucht, danach per NetBIOS-Broadcast via UDP-Port 138, danach per NetBEUI (LLC plus NetBIOS plus SMB, sofern geladen); am Ende wird womöglich noch die LMHOSTSDatei herangezogen. Schon diese Abfolgen können bizarre Ergebnisse liefern, sind aber doch immerhin aus gutem Grunde erfunden worden. Was wir in den folgenden Beispielen jedoch an Fehlern sehen werden, ist teilweise weit jenseits des guten Geschmacks. Es sei zudem auf die Kapitel zur Layer-7-Analyse hingewiesen, die ebenfalls Beispiele zu Name Service-Fehlern enthalten. Insbesondere sei dem Leser empfohlen, die Windows-XP-Fallstudie zu Rate zu ziehen. Alle folgenden Beispiele wurden anonymisiert. Das heißt: Die Domain-Namen wurden ausgetauscht, zum Beispiel gegen sample.de. Auch IP-Adressen wurden ausgetauscht, um Rückschlüsse auf die Datennetze zu verhindern, in denen die Messungen jeweils vorgenommen worden waren. Die Anonymisierung wurde mit dem TraceMagic-Modul TraceAnon (Trace Anonymizer) vorgenommen; dieses erlaubt, Rechner- und Domänen-Namen sowie IP-Adressen auszutauschen. Darüber hinaus (und hier nicht genutzt) bietet es die Möglichkeit, die binären Aufzeichnungsdaten (Trace Files) komplett ihrer Nutzdaten zu berauben, indem alle Inhalte oberhalb der Transportprotokolle durch Nullen (0x0000..) ersetzt werden. Diese Funktionen wurden im Wesentlichen mit Rücksicht auf geheimhaltungsbedürftige Kunden wie beispielsweise die Bundeswehr entwickelt, die noch nicht einmal die Text-Reports von TraceMagic zur Durchsicht an Externe weitergeben darf, wenn nicht IPAdressen und Rechnernamen anonymisiert sind.

9.1 Dateisuche per DNS Quelle: Düsseldorf(Vorort), 2001

Hier werden wir gleich mit der ganzen Wucht des Einfallsreichtums erfasst, mit denen Windows-Clients versuchen, ihrem Herrchen zu helfen, das Stöckchen zu finden, das er da wohl sucht. Denn Windows-Clients sind manchmal wie gut erzogene Schoßhündchen, die allem hinterherlaufen, was man ihnen vorhält und dann wegwirft. Hier haben Windows-Clients versucht (in den Screen Shots nicht zu sehen), verschiedene Dateien auf Windows-Servern zu laden. Die Server jedoch haben die Dateien nicht. Hierbei kann es offen bleiben, ob der Client am richtigen Ort gesucht hat (und der Server die Datei nicht hat oder nicht geben mag) oder ob der Client am falschen Ort gesucht hat (und der Server zu Recht die Zugriffe abwehrt). Sodann kann es geschehen, dass Windows-Clients überlegen: »Hm, wie könnte ich jetzt noch meinem Herrchen helfen?«

360

>>> NEW TECH

Dateisuche per DNS

Keine Frage: Wenn File Server nicht helfen können, fragen wir eben Name Server! Das sind ja auch Server. Das kann dann zu folgenden Abfragen führen: Listing 9.1: Liste der zum Teil beispielhaft falschen DNS-Anfragen, die verkappte Datei-Anfragen sind MATYS.intern.sampled.de MATYS.sampled.de MATYSCD-ROM MATYSDATAMAINLIST.DAT SLANT010.intern.sampled.de Slant010.intern.sampled.de slant010.intern.sampled.de SLANT010DLABUHL01.intern.sampled.de SLANT010DLABUHL01.sample.de SLANT010DLABUHL01.sampled.de SLANT010DLAEXHT01.intern.sampled.de SLANT010DLAEXHT01.sampled.de SLANT010DLAKBHL013.intern.sampled.de SLANT010DLAKBHL013.sampled.de SLANT010DLAKBHT01.intern.sampled.de SLANT010DLAKBHT01.sampled.de SLANT010NETLOGONCONFIG.POL SLANT011.intern.sampled.de SLANT011.Intern.sampleD.DE slant011.intern.sampled.de SLANT011DOKUMENTE.sample.de SLANT011DOKUMENTEAnwendungenHyperionFHC_2000error.log SLANT011WADLE$BRIEFE01hjhDokument3.intern.sampled.de SLANT011WADLE$BRIEFE01hjhDokument3.sampled.de SLANT011WADLE$BRIEFE01hjhfoo.intern.sampled.de SLANT011WADLE$BRIEFE01hjhfoo.sampled.de slant011x.intern.sampled.de SLANT012.intern.sampled.de Slant012.intern.sampled.de SLANT012LVSECHTSOFTWARELVS.DWX

9.1.1

Ergebnistabelle von TraceMagic/HostMagic

Die Textausgabe der Auswertungstabelle bei TraceMagic (Ausschnitt siehe Abbildung) stellt sämtliche DNS-Namen dar, die von Clients angefragt wurden, samt Anzahl der Anfragen (Gesamt:[Unicasts/Broadcasts]) und Anzahl der Antworten (Gesamt:[Erfolg/Misserfolg]). Es wird schnell ersichtlich, dass dort vermeintliche DNS-Namen auftauchen, die kaum DNS-Namen sein können. Bei näherem Hinsehen zeigt sich eben, dass es sich um Pfadangaben handelt (Server-Namen plus Verzeichnis-/Dateinamen), die – sämtlicher Sonderzeichen wie Backslash beraubt – nunmehr in der DNS-Syntax abgefragt werden.

>>> NEW TECH

361

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

Abbildung 9.1: TraceMagic/HostMagic: Tabelle mit Auswertung der DNS-Abfragen (A)

Abbildung 9.2: TraceMagic/HostMagic: Tabelle mit Auswertung der DNS-Abfragen (B)

In den folgenden Beispielen werden einige Vorgänge um \NETLOGON\CONFIG.POL, Cretschmar.doc und ATC.doc näher ausgeführt.

9.1.2

DNS-Anfragen nach SLANT010DLAKBHT01

Bei dieser Anfrage handelt es sich um die Verfälschung eines Verzeichniszugriffs: UNC = \\SLANT010\DLAKBHT01 Server = SLANT010 Verzeichnis = \DLAKBHT01

9.1.3

DNS-Anfragen nach SLANT010NETLOGONCONFIG.POL

Bei dieser Anfrage handelt es sich um die Verfälschung des folgenden Dateizugriffs: UNC = \\SLANT010\NETLOGON\CONFIG.POL Server = SLANT010 Verzeichnis = \NETLOGON Datei = \CONFIG.POL

362

>>> NEW TECH

Dateisuche per DNS

Abbildung 9.3: DNS-Anfragen nach SLANT010DLAKBHT01 (Server-Name plus Verzeichnispfad)

Für den DNS-Zugriff werden alle Sonderzeichen entfernt. Nur die DateiEndung .POL bleibt erhalten, da sie ja der DNS-Namenskonvention nicht widerspricht – im Gegenteil! Und schon gibt es eine vermeintliche, neue Top-LevelDomain (.POL).

Abbildung 9.4: DNS-Anfragen nach SLANT010NETLOGONCONFIG.POL (Server-Name plus Datei-Pfad)

Es ergibt sich, dass der Client die DNS-Anfragen mehrfach wiederholt, da es keine Adressauflösung bzw. keine Rückgabe einer IP-Adresse betreffend SLANT010NETLOGONCONFIG.POL seitens des DNS-Servers gibt.

>>> NEW TECH

363

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

Abbildung 9.5: Die Suche nach SLANT010NETLOGONCONFIG.POL via DNS dauert hier mindestens 30 Sekunden, weil der DNS-Server jeweils im Internet nachfragt (hier nicht zu sehen).

Man muss immer einrechnen, dass ja reguläre Client-Requests über die File Services vorangegangen waren, die ebenfalls scheiterten (und nur wegen dieses Scheiterns kommt es zum Verzweiflungsakt der DNS-Anfragen). Alles zusammen gerechnet, ergeben sich noch wesentlich längere Wartezeiten als die hier in Abbildung 9.5 sichtbaren 30 Sekunden.

9.1.4

DNS-Anfragen nach SLANT011.Intern.sampleD.DE

Diese DNS-Anfrage ist völlig korrekt und wurde hier mit in die Darstellung aufgenommen, um zu zeigen, dass es sich bei SLANT010, SLANT011, SLANT012 etc. um echte Server-Namen handelt, die auch in IP-Adressen aufgelöst werden können.

Abbildung 9.6: DNS-Anfragen nach SLANT011.Intern.sampleD.DE (korrekte DNS-Anfrage, die auch aufgelöst wird in IP = 22.5.1.10)

364

>>> NEW TECH

Dateisuche per DNS

Daraus ergibt sich, dass bei irregulären DNS-Anfragen wie etwa SLANT012LVS ECHTSOFTWARELVS.DWX wenigstens teilweise reguläre Versatzstücke auftauchen (nämlich die Server-Namen).

9.1.5

DNS-Anfragen nach SLANT011WADLE$BRIEFE01jhjfoo

Dieser Pfad ist doppelt interessant: Er beinhaltet ein Share und ein Phantom namens foo. UNC = \\SLANT011\WADLE$\BRIEFE01\jhj\foo Server = SLANT011 Share = WADLE$ Verzeichnis = \jhj Datei = \foo

Ja foo – dieses Phantom geistert durch praktisch alle Netzwerke. Foo ist als Dummy in den USA für Programmierer ungefähr das, was für die Europäer etwa »test« wäre. Immer wieder ist zu finden, dass Programmierer in ihrem Code mit foo arbeiten – offenkundig in Test-Routinen, die sie hinterher zu entfernen vergaßen. So wird dann eben auf ewig-und-drei-Tage nach foo gesucht. Nicht nur, dass dies sowieso die Applikations-Funktionen verzögert, – nein, die Katastrophe liegt (wenigstens im vorliegenden Fall) darin, dass bei jedem fehlgeschlagenen Dateizugriff zusätzlich die Namensdienste bemüht werden: völlig sinnlos und sogar schädlich, weil es den DNS-Server unter zusätzliche Last setzt.

Abbildung 9.7: DNS-Anfragen nach SLANT011WADLE$BRIEFE01jhjfoo (Server-Name plus Datei-Pfad)

Außerdem haben einige DNS-Server (Windows NT4-SP4 mit Standardkonfiguration) die interessante Angewohnheit, solche Anfragen ins Internet weiterzu>>> NEW TECH

365

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

leiten, wo sie teilweise bis zu den DNS-Root-Servern in Austin, Texas, USA, weitergereicht werden. Die hierbei auftretenden Timeouts können 2 Minuten weit übersteigen und sind somit evident ein Grund für Aussagen der Anwender: »Das Netzwerk ist langsam.«

9.1.6

DNS-Anfragen nach JSPNRMPTGSBSSDIR

Bei diesem geschmackvollen Namen handelt es sich um ein Phantom, dessen Herkunft nicht ganz klar ist. Es gibt Einträge in der Microsoft Knowledgebase, die bis ins Jahr 1996 zurückreichen und Zusammenhänge herstellen zwischen RAS-Servern (RAS Dial-In Service) und WINS/DNS.

Abbildung 9.8: Microsoft Knowledgebase zum Problem mit JSPNRMPTGSBSSDIR (Lösungsvorschlag, der jedoch die Herkunft ebenfalls nicht klärt – ebenso wenig wie andere KB-Einträge)

366

>>> NEW TECH

Dateisuche per DNS

Tatsache ist, dass Windows-Rechner auf der ganzen Welt diesen PhantomNamen (dem keine reale NetBIOS-Ressource entspricht) kennen und nach ihm suchen – per Name Server sowie per Broadcast. Ein paar der Microsoft Knowledgebase-Artikel haben die Nummern: KB150820, KB151475, KB194562. Microsoft empfiehlt, zur Vermeidung von Name Service-Anfragen das Folgende zu tun: statische Einträge in den WINS- und DNS-Servern vornehmen (was manuell zu erledigen wäre) oder einen lokalen Eintrag in der jeweiligen LMHOSTS-Datei der betroffenen Maschinen. Diese Vorgehensweise empfiehlt sich auch bei allen anderen Phantom-Namen, die in einem Netzwerk auftreten. Der Verfasser hat selbst bei mehreren Kunden die Erfahrung gemacht, dass Dummy-Einträge in den Name-Servern dazu führen, dass die Clients nach erstmaliger Abfrage zufrieden sind (weil der Name sodann vermeintlich verifiziert ist) und die nachfolgenden Abfragen und Broadcasts unterlassen – mit der Folge, dass Anwender das ab und an lobend erwähnen. »Mensch – ist das Netzwerk schnell geworden!« Na, siehste wohl: Netzwerk-Analyse hat manchmal auch etwas Gutes!

Abbildung 9.9: DNS-Anfragen nach JSPNRMPTGSBSSDIR (NetBIOS-Phantom-Name)

Im vorliegenden Fall (siehe Abbildung) besteht das Problematische der Situation darin, dass die unsinnigen DNS-Abfragen nach JSPNRMPTGSBSSDIR an alle bekannten DNS-Server weitergereicht werden – die auch alle nicht helfen können. Jedes Mal (für jede einzelne dieser Anfragen!) muss gewartet werden, bis die Zeitüberschreitung eingetreten ist. Es wird schnell klar, dass dieser Zustand für die Anwender, die vor dem Bildschirm sitzen und warten, unhaltbar ist.

>>> NEW TECH

367

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

Für den DNS-Server kann das bedeuten, dass er dermaßen viele DNS-Requests ins Internet offen hält, dass er Ressourcen-Probleme bekommt und selbst harmlose, reguläre lokale DNS-Anfragen nicht mehr bedienen kann: entweder nicht mehr zeitgerecht (also auch mit Timeout), oder überhaupt nicht mehr (was eine Server Error-Meldung erzeugt). Es wurde bereits darauf hingewiesen, dass unter solchen Umständen eine einzige DNS-Anfrage weit länger als zwei Minuten schwebend sein kann. Stelle man sich nunmehr weiterhin vor, dass – aus welchen Gründen auch immer – ein Client ein Dutzend solcher Anfragen verschickt hat, so können Wartezeiten auflaufen, die jenseits von Gut und Böse sind. Bei verschiedenen Kunden hat der Verfasser bei solchen Szenarien Wartezeiten von 10 bis 20 Minuten erlebt. Das ist zwar die Ausnahme, aber es ist möglich.

9.1.7

DNS-Anfragen nach SLANT012LVSECHTSOFTWARELVS.DWX

Dieser Pfad weist auf eine Datei oder ein Verzeichnis namens LVS.DWX. UNC = \\SLANT012\LVS\ECHT\SOFTWARE\LVS.DWX Server = SLANT012 Verzeichnis = \LVS\ECHT\SOFTWARE Datei = \LVS.DWX

Auch hier wird – wie in anderen Beispielen ebenfalls – aus einer Datei-Endung eine neue DNS-Top-Level-Domain (.DWX). Entsprechende Abfragen ins Internet bleiben nicht aus. Doch auch die DNS-Root-Server in Austin, Texas, USA, können hier kaum helfen!

Abbildung 9.10: DNS-Anfragen nach SLANT012LVSECHTSOFTWARELVS.DWX (Server-Name plus Datei-Pfad)

368

>>> NEW TECH

Dateisuche per DNS

Die Aufmerksamkeit des Betrachters wird u.a. erweckt durch die ErgebnisStatistik der Datei-Fehlzugriffe. Diese Statistik wird erzeugt durch eine Auswertung im TraceMagic-Modul SpiderMagic (siehe Abbildung 9.11).

Abbildung 9.11: Das TraceMagic-Modul TraceStatistics mit den Auswertungsergebnissen zu DateiFehlzugriffen

In der Praxis sieht das dann so aus wie in Abbildung 9.12 zu sehen: Der Client IP = 22.5.101.58 versucht, die Datei (oder das Unterverzeichnis) \SOFTWARE\LVS.DWX auf Server IP = 22.5.1.12 zu finden. Die Zugriffsversuche werden in der EVENT-LOG-Datei von TraceMagic als ACCESS_FAILURE gekennzeichnet (Zugriffsfehler), da der Server jeweils statt der Datei bzw. statt des FileHandles einen Error-Code zurückgibt und zwar den Fehler-Code 0x01000200 für »File Not Found« (Datei nicht gefunden). Da diese Zugriffsversuche sämtlich fehlschlagen (und das zu hunderten, da der Client sie ständig wiederholt), verfällt der Windows-Rechner auf die Idee, nicht nur die Datei-Dienste, sondern auch die Namensdienste zu bemühen. Daraus ergeben sich dann in reicher Zahl DNS-Anfragen nach SLANT012LVSECHTSOFTWARELVS.DWX, was ursprünglich bedeutet: \\SLANT012\LVS\ECHT\SOFTWARE\LVS.DWX (siehe oben). Da die Dateizugriffe sich auf das Verzeichnis \SOFTWARE richten, ist davon auszugehen, dass das Share auf das Verzeichnis \\SLANT012\LVS\ECHT gelegt ist. Nun also nimmt der Client-PC den vollen UNC-Pfad (UNC: Universal Naming Convention), entfernt die Sonderzeichen (hier die Schrägstriche) und übergibt das Ganze als DNS-Anfragen dem nächsten DNS-Server.

>>> NEW TECH

369

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

Abbildung 9.12: DNS-Anfragen nach SLANT012LVSECHTSOFTWARELVS.DWX sowie fehlschlagende Dateizugriffe auf LVS.DWX

370

>>> NEW TECH

Dateisuche per DNS

Warum bei solchen Ereignissen das »Netzwerk langsam« wird, wird klar, wenn man einen Filter auf DNS-Anfragen sowie auf ICMP-Meldungen setzt. Es ergibt sich, dass der Client die DNS-Anfragen mehrfach wiederholt; Grund: Weil die jeweils vorangegangene Anfrage ohne Ergebnis blieb. Ja, aber die Absage des DNS-Servers stellt doch auch ein Ergebnis dar? Ja, aber wenn der Client die jeweilige Antwort des DNS-Servers gar nicht mehr aufnimmt, weil ein Timeout dazu führte, dass der UDP-Socket für den Client-DNS-Request schon längst geschlossen wurde, bevor die Antwort des DNS-Servers eintraf, dann stellt sich das Ganze dem Client gegenüber so dar (auf der Ebene des DNS-Treibers), dass es überhaupt niemals Antworten des DNS-Servers gegeben hat! Und in diesem Fall löst der DNS-Treiber des Clients jeweils eine neue Anfrage aus. So vervielfältigen sich die Wartezeiten, während derer die Applikation (die hinter dem Ganzen steht und die eigentlich nur mal nach LVS.DWX gefragt hatte) weiterhin blockiert ist und die letzte Zeitüberschreitung abwartet.

Abbildung 9.13: Die Suche nach SLANT012LVSECHTSOFTWARELVS.DWX geht hier über rund 50 Sekunden. Die Antworten des DNS-Servers treffen zu spät ein, der Client sendet ICMP: Destination unreachable/Port unavailable.

Die ICMP-Meldungen des Clients mit der Nachricht Destination unreachable/ Port unavailable zeigen, dass die vom Client erwartete Antwortzeit des DNSServers überschritten wurde. Die lange Antwortzeit des DNS-Servers erklärt sich wiederum daraus, dass dieser nach der vermeintlich neuen Top-Level-Domain .DWX im Internet recherchiert, bis hin zu den DNS-Root-Servern in Austin, Texas, USA (hier im Bild nicht zu sehen).

>>> NEW TECH

371

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

Im vorliegenden Beispiel gehen allein bei diesen Abfragen 50 Sekunden reiner Wartezeit verloren – die vorangegangenen Datei-Anfragen nicht mitgerechnet. Vermutlich also sitzt der Anwender eine ganze Minute (wenn nicht länger) vor seinem Bildschirm, wartet – und kommt zu dem Schluss: »Das Netzwerk ist langsam.« Das ist, wie wir nun sehen, genauso richtig wie es zugleich falsch ist.

9.1.8

DNS-Anfragen nach SLANT012LVSECHTSOFTWAREWinlvs5.exe

Dieser Pfad weist auf eine Datei oder ein Verzeichnis namens WinLVS5.EXE. UNC = \\SLANT012\LVS\ECHT\SOFTWARE\WinLVS5.EXE Server = SLANT012 Verzeichnis = \LVS\ECHT\SOFTWARE Datei = \ WinLVS5.EXE

Auch hier wird – wie in anderen Beispielen ebenfalls – aus einer Datei-Endung eine neue DNS-Top-Level-Domain (.EXE) (siehe Abbildung 9.14). Und wieder ist zu sehen, dass die Antwortzeiten des DNS-Servers zu lang für den Client sind. Auf jeden DNS-Reply des DNS-Servers erwidert der Client mittels ICMP, dass er leider mit dem Datenpaket nichts anfangen könne, weil der entsprechende UDP-Port der DNS-Anfragen jeweils schon geschlossen worden sei. Je nachdem, wie der Server eingestellt ist, kann es sein, dass er nun mehrfach seine DNS-Antwort, dass er leider die Auflösung nicht bieten könne, per Wiederholung an den Client schickt (weil Antworten ja wichtig sind und gefälligst vom Client zur Kenntnis genommen werden sollen) und zwar an genau den UDP-Port, von welchem der Server just erfahren hat, dass er nicht mehr aktiv ist, weil er schon auf Grund einer Zeitüberschreitung geschlossen worden war – es ist wirklich die reine Freude.

9.1.9

DNS-Anfragen nach MATYSDATAMAINLIST.DAT

Dieser Pfad weist auf die Datei MAINLIST.DAT. UNC = \\MATYS\DATA\MAINLIST.DAT Server = MATYS Verzeichnis = \DATA Datei = \MAINLIST.DAT

Auch hier wird – wie in anderen Beispielen ebenfalls – aus einer Datei-Endung eine neue DNS-Top-Level-Domain (.DAT) (siehe Abbildung 9.15).

372

>>> NEW TECH

Dateisuche per DNS

Abbildung 9.14: DNS-Anfragen nach SLANT012LVSECHTSOFTWAREWinlvs5.exe >>> NEW TECH

373

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

Abbildung 9.15: DNS-Anfragen nach MATYSDATAMAINLIST.DAT (Server-Name plus Datei-Pfad)

9.1.10 DNS-Anfragen nach SLANT011DOKUMENTEAbteilungenDExport TrogsangDiverseCretschmar.doc Bei dieser Anfrage handelt es sich um die Verfälschung des folgenden Dateizugriffs: UNC = \\SLANT011\DOKUMENTE\AbteilungenD\Export\Trogsang\Diverse\Cretschmar.doc Server = SLANT011 Verzeichnis = \DOKUMENTE\AbteilungenD\Export\Trogsang\Diverse Datei = \Cretschmar.doc

Dieses Beispiel gibt Aufschluss über den Hergang der Ereignisse, sofern die Datendialoge des Clients beobachtet werden. Sie zeigen, wie es zu solchen bizarren Ergebnissen kommen kann. In Abbildung 9.16 ist der Ereignisablauf zu sehen, der zu der skurrilen DNSAnfrage führt. Die Darstellung ist etwas verkürzt, da am linken Bildrand von den IP-Adressen der Empfänger nur jeweils der Rest »119« zu sehen ist. Die IPAdressen von Sender und Empfänger ergeben sich aber immer noch aus den vollständig sichtbaren IP-Adressen des jeweiligen Absenders.

374

>>> NEW TECH

Dateisuche per DNS

Abbildung 9.16: TraceMagic Event-Log: Ereignisablauf beim Versuch des Clients, mit der Datei CRETSCHMAR.DOC zu arbeiten – endend in falschen DNS-Anfragen

>>> NEW TECH

375

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

Der Reihe nach sind folgende Vorgänge zu sehen: ■

■

■

■

■

Die Datei CRETSCHMAR.DOC wird mehrfach geöffnet. Teilweise wird sie parallel ein zweites Mal geöffnet und das File-Handle für den jeweils neuen Zugriff vom Server empfangen, bevor der vorige Dateizugriff beendet bzw. das vorige File-Handle an den Server zurückgegeben wird (File Close). Dies ist ein beachtlicher Vorgang in verschiedener Hinsicht: Erstens sollte eine Applikation eine Datei einmal laden und dann damit arbeiten – und sie nicht mehrfach hintereinander laden. Zweitens sollte für den Fall, dass sie nun doch mehrfach hintereinander geöffnet werden muss, der Zugriff so geregelt sein, dass die Datei erst geschlossen und dann wieder geöffnet wird bzw. dass erst das alte (noch aktuelle) File-Handle an den Server zurückgegeben wird, bevor für den nächsten Zugriff ein neues angefragt wird. Nach den ersten Zugriffen auf CRETSCHMAR.DOC wird der Zugriff variiert, indem versucht wird, auf MCF-CRETSCHMAR.DOC zuzugreifen – was jedoch scheitert, weil es eine Datei solchen Namens nicht gibt. Diese Variante ist sehr häufig zu sehen: Dateinamen werden durch Veränderungen mutiert ohne Rücksicht auf reale Gegebenheiten. Danach wiederum wird versucht, auf eine der Datei CRETSCHMAR.DOC zugeordnete Temp-Datei namens ~$ETSCHMAR.DOC zuzugreifen (Achtung: Großbuchstaben!), was ebenfalls misslingt. Dieser Vorgang könnte insofern planmäßig und normal sein, als das Abprüfen der Existenz einer solchen Datei geboten sein könnte. Hier jedoch antwortet der Server jedes Mal: File Not Found. Nach diesen Versuchen wird statt nach ~$ETSCHMAR.DOC (Großbuchstaben!) nach ~$etschmar.doc gesucht – und nunmehr stellt sich Erfolg ein, denn der Server gibt ein File-Handle zurück (0x1005). Unmittelbar darauf wird die Temp-Datei wieder geschlossen. Es muss gefragt werden, warum der Server nicht in der Lage ist, unabhängig von der Groß-/Klein-Schreibung (case insensitive) die Datei zu finden bzw. warum es die Leistung des Clients zu sein hat, die verschiedenen Möglichkeiten zu durchlaufen. Im vorliegenden Fall könnte eine Rolle spielen, dass Windows NT-Server als Emulation aus AS/400-Maschinen liefen (was aber nicht sicher ist). Nunmehr kommt der Client auf die großartige Idee, den Dateizugriff (der ja längst stattgefunden hat) abzurunden mit einer Anfrage an den DNS-Server, ob der einen um die Schrägstriche beraubten Datei-Pfad wohl in eine IPAdresse umsetzen könne. Nein, kann er nicht – daher findet sich in dem Event-Log von TraceMagic auch die Darstellung 0.0.0.0 als Symbol für die nicht erfolgte Auflösung des vermeintlichen DNS-Namens in eine IPAdresse.

Dateizugriffe sind bei TraceMagic nicht nur im Event-Log nachzuvollziehen. Sie werden außerdem immer in einer separaten Tabelle nachgewiesen, die den Zugriffsbefehl (Protokoll-Code) nachweist, einen etwaigen Error-Code (im Falle eines Misserfolgs), ein etwaiges File-Handle (im Falle des Erfolgs) sowie den Dateinamen, der seitens des jeweiligen Clients angefragt wurde. Ein Sternchen weist immer auf Fehlversuche hin (bei denen der Server die angefragte Datei nicht fand und oder nicht herausgeben durfte).

376

>>> NEW TECH

Dateisuche per DNS

Abbildung 9.17: TraceMagic/SpiderMagic: Tabelle mit dem Nachweis aller Dateizugriffe einschließlich der Dateinamen und File-Handles, hier: CRETSCHMAR.DOC mit den File-Handles 0x080D, 0x080E, 0x080F,0x1000

Drei Punkte in der Spalte der Dateinamen stehen symbolisch für den CloseFile()-Befehl des Clients bzw. für die Rückgabe des File-Handles an den Server. Man bedenke, dass wir uns hier eigentlich im Kapitel über die Name Services bzw. Namensdienste befinden! Stattdessen sind wir – schwupps! – im weiten Reich der File Services bzw. Datei-Dienste gelandet.

9.1.11 DNS-Anfragen nach SLANT011WADLE$BRIEFE01hjhATC.doc Bei dieser Anfrage handelt es sich um die Verfälschung des folgenden Dateizugriffs: UNC = \\SLANT011\WADLE$\Briefe\01\HJH\ATC.doc Server = SLANT011 Share = WADLE$ Verzeichnis = \Briefe\01\HJH Datei = \ATC.doc

Der Hergang der Ereignisse lässt sich wie folgt zusammenfassen (siehe das Event-Log von TraceMagic in Abbildung 9.18 sowie die Liste der DHCP-Werte in Abbildung 9.19): ■

■ ■

Zunächst wird versucht, den Namen des Servers SLANT011 in die IP-Adresse aufzulösen durch Anruf des WINS-Servers IP = 22.5.1.10; dieser Versuch schlägt fehl. Sodann wird der Versuch durch Anruf des WINS-Servers IP = 22.5.1.11 wiederholt. Bei IP = 22.5.1.10 handelt es sich um den Primary WINS-Server, bei IP = 22.5.1.11 um den Secondary WINS-Server. Man beachte: Der Primary WINS-Server kennt einen der wichtigsten NT-Server nicht! Hier darf man

>>> NEW TECH

377

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

sich wirklich bald überhaupt nicht mehr wundern, wenn massenhaft Fehler auftreten, denn es ist kaum anzunehmen, dass dieser Zustand gewollt ist. Wie sieht es mit dem Tabellenabgleich der WINS-Server untereinander aus? Hier werden Fehler sichtbar, die an den Nerv der Netzwerk-Logik gehen können.

Abbildung 9.18: TraceMagic Event-Log: Ereignisablauf beim Versuch des Clients, mit der Datei ATC.DOC zu arbeiten – endend in falschen DNS-Anfragen

378

>>> NEW TECH

Dateisuche per DNS

Abbildung 9.19: TraceMagic/HostMagic: Liste mit den vom DHCP-Server an Clients zurückgegebenen Parametern; hier von Bedeutung: WINS-Server IP = 22.5.1.10/11 ■

■

■ ■

■

Sodann greift der Client IP = 22.5.101.122 auf ein Windows-Share des Servers zu: \\SLANT011\WADLE$. Der Server bestätigt den Zugriff und somit hat der Client die Möglichkeit, in der Folge auf Dateien dieses Shares zuzugreifen. Der Zugriff auf das Share führt beim Client intern zur Bildung eines Netzwerk-Laufwerks; dieses ist jedoch nicht zu verwechseln mit der im Event-Log zu sehenden Angabe A: (das hat historisch andere Gründe, bezeichnet jedenfalls nicht einen lokalen Laufwerksbuchstaben des Clients, auch nicht des Servers). Danach wird ein IPC-Zugriff eingeleitet: \\SLANT011\IPC$. IPC steht für Inter Process Communication. Derartige Zugriffe richten sich nicht wirklich auf einen Ort auf der Festplatte des Servers, sondern begleiten andere Client/Server-Zugriffe. Danach wird der Zugriff auf ein weiteres Share initialisiert: \\SLANT011\ DOKUMENTE. Unmittelbar darauf wird dieses Share-Handle auf \\SLANT011\IPC$ wieder aufgelöst (Tree Disconnect). Dieser Vorgang ist in Abbildung 9.20 zu sehen: Die beiden Client-Befehle Tree Connect und Tree Disconnect sind dort gut nachzuvollziehen. Dass sich die beiden Kommandos auf denselben Gegenstand beziehen, ergibt sich aus den Parametern Network Path/Tree ID, Process ID und User ID. Der Wert für Tree ID ist beim ersten Befehl Tree Connect noch auf 0x0000 gesetzt, da ja erst die darauf folgende Antwort des Servers die Zuweisung des File-Handles bzw. des Share-Handles darstellt. \\BRIEFE\01\HJH\MCF-ATC.DOC – Dieser Versuch, die Datei ATC.DOC zu finden, weist eine nicht seltene Mutation des Dateinamens auf, indem ein MCF-

vorangestellt wurde. MCF ist die Abkürzung für Meta Content Format, das 1996 von Apple vorgestellt wurde und system- bzw. plattformunabhängig Datei-Systeme verbessern sollte. Diese Zugriffsversuche schlagen fehl.

>>> NEW TECH

379

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

Abbildung 9.20: SMB Tree Connect (links): Der Zugriff auf das virtuelle IPC-Share wird eingeleitet (ClientRequest). SMB Tree Disconnect (rechts): Der IPC-Zugriff wird beendet (Client-Request). ■

■

■

380

\\BRIEFE\01\HJH\ATC.DOC – Diese Dateizugriffe gehen in Ordnung; der Server antwortet jedes Mal mit der Herausgabe des jeweiligen File-Handles. Zweimal unmittelbar hintereinander wird die Datei geöffnet und sofort wieder geschlossen (was auch bei tolerantester Sicht allenfalls noch Sinn ergibt, wenn der Programmierer austesten wollte, ob die Zugriffe überhaupt funktionieren, bevor sie »echt« vorgenommen werden). Erst der dritte Zugriff »beschäftigt« sich dann mit der Datei. \\BRIEFE\01\HJH\~$ATC.DOC – Während noch die Datei ATC.DOC geöffnet bleibt (während also das darauf gerichtete File-Handle weiter aktiv ist), wird nach Temp-Dateien gesucht, die als Abkömmlinge von ATC.DOC existieren könnten. Die Angabe ACCESS_FAILURE im Event-Log von TraceMagic stellt eine Wertung dar, insofern der Server jedes Mal auf diese Anfrage nicht etwa einen File-Handle zurückgibt, sondern einen Error-Code (im Event-Log dargestellt als SRVR_ERRORCODE), was bedeutet, dass kein Zugriff stattfinden kann, etwa weil es diese Datei nicht gibt oder weil der Zugriff nicht gestattet ist. Es darf vermutet werden, dass die Applikation fest vom Zugriff auf die Word-Temp-Dateien ausgegangen ist bzw. mit diesem Zugriff gerechnet hat. Grund für diese Vermutung ist die nachfolgende Reaktion des DNSTreibers. Die völlig kranke DNS-Anfrage richtet sich zwar auf die Datei ATC.DOC, erfolgt aber unmittelbar nach dem fehlgeschlagenen Versuch,

>>> NEW TECH

Dateisuche per DNS

~$ATC.DOC zu laden, und da aus dem DNS-Zeichenstrang alle Sonderzeichen gelöscht wurden, bleibt eben von ~$ATC.DOC nur noch ATC.DOC übrig (dieser

■

Deutung jedoch widerspricht, dass das Dollarzeichen am Ende der ShareBezeichnung WADLE$ stehen geblieben ist). Offenkundig scheint es so zu sein, dass im Client ein Software-Interrupt zur Fehlerbehebung ausgelöst wurde: und wenn schon die Namensdienste untereinander stets einspringen, um Ersatzwege für fehlgeschlagene Namens- und Adressauflösungen zu gehen – warum dann eben nicht für einen fehlgeschlagenen Dateizugriff? So jedenfalls scheint sich das im Innern des Windows-Clients abzuspielen. SLANT011WADLE$BRIEFE01hjhATC.doc – Nun also erfolgt zu guter Letzt die völlig unzulässige DNS-Anfrage, die letztlich nur aus einem Pfad- und Dateinamen besteht.

Ein zulässiger Grund für die völlig irre DNS-Anfrage ist nicht ersichtlich, nur der Zusammenhang mit dem vorigen Dateizugriff bleibt greifbar: Klar ersichtlich ist der Zusammenhang zum vorigen Initialisieren des Share-Zugriffs sowie dem nachfolgenden Datei-Pfad auf ATC.DOC.

Abbildung 9.21: TraceMagic/SpiderMagic: Tabelle mit dem Nachweis aller Dateizugriffe einschließlich der Dateinamen und File-Handles, hier: ARC.DOC bzw. ~$ATC.DOC mit den File-Handles 0x080D, 0x0801, 0x0802,0x0803

Auch hier wieder bleibt als Fazit, dass der Kunde schnellstens von Fast Ethernet auf Gigabit-Ethernet umsteigen muss oder von Gigabit auf Terabit oder auf das Beamen von Daten via Subraumfrequenzen mittels des Traktorstrahls, denn keine Frage: »Das Netzwerk ist langsam.« Wenn der Anwender wartet, muss aufgerüstet werden! So verdient die Hardware-Industrie und das schon seit Jahren. Man hätte nur mal genau(er) hinsehen müssen. Man hätte nur mal Analyzer kaufen müssen, welche diese Zusammenhänge strukturiert und umfassend nachweisen und sichtbar machen. So aber wurden Millionen über Jahre verschleudert und heute fehlt das Geld.

>>> NEW TECH

381

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

9.2 Script-Reparatur per DNS Quelle: Koblenz, 2002

Das nun folgende Beispiel enthält weitgehend alle Zutaten des zuvor dargestellten Szenarios (9.1), geht aber noch weit darüber hinaus, weil das Giftgebräu nun weit mehr Beigaben aufweist, und damit ist gemeint: die Durchmischung von Windows-Treibern mit Novell NetWare-Treibern. Überall dort, wo Windows-Clients neben den Microsoft-Netzwerk-Treibern auch die Novell NetWare Client-Requester (Client-Treiber) verwenden, muss mit dem Äußersten gerechnet werden, was an Wahnsinn überhaupt noch denkbar ist. Der geneigte Leser glaubt, hier werde übertrieben? Nun, wir werden ja sehen. Die Anwender des Kunden, in dessen Netzwerk diese Abläufe erkannt wurden, mussten morgens zum Teil 10 bis 20 Minuten warten (!!), bis nach Eingabe von Benutzername/Passwort der Anmeldevorgang beendet und der Bildschirm zur weiteren Arbeit frei war. Es dürfte wohl klar sein, dass sich derlei Zeitverhalten weit jenseits aller toleranten Schmerzgrenzen befindet.

9.2.1

DNS-Namen werden in der NetWare-NDS gesucht

Im Gegensatz zum Beispiel in 9.1 werden hier nun nicht Datei-Anfragen ersatzweise über DNS angestrebt, sondern DNS-Anfragen ihrerseits in ein DNS-fremdes System überführt, nämlich in die Baumstruktur der NetWare Directory Services (NDS). Dem könnte man insofern einen Sinn abgewinnen, als ja möglich erscheinen muss, dass Rechner (insbesondere Server) sowohl in der DNSStruktur als auch in der NDS-Struktur mit Namen vertreten sein könnten (oder von der einen in die andere Struktur migriert worden sein könnten). Nur: Bei so genannten voll qualifizierten DNS-Namen (FQN = Full Qualified Name) ist der Zweifel angebracht: Was soll die Suche nach www.msn.de etc. in der NDS? In den Beispielen, die in Abbildung 9.22 und Abbildung 9.23 zu sehen sind, taucht ein Teil der NDS-Baum-Struktur auf: .Factory.4922.bs.li

In diesem Teilbaum der gesamten NDS-Struktur werden die DNS-Namen gesucht. Das Zeitverhalten (hier nicht in den Abbildungen erkennbar) zeigt übrigens, dass die Auflösungsversuche via DNS und NDS praktisch gleichzeitig erfolgen. Das heißt der Client wartet nicht ab, bis eine Antwort vom NDS-Server eintrifft oder die Zeitüberschreitung gegeben ist, sondern schickt sofort nach dem NDSRequest die DNS-Anfrage fort. Dies hat wenigstens für den Anwender den Vorteil, dass sich – in diesem Falle – keine weiteren Wartezeiten einstellen.

382

>>> NEW TECH

Script-Reparatur per DNS

Abbildung 9.22: TraceMagic/Event-Log: Die Auflösung von DNS-Namen wie popup.msn.com in IP-Adressen wird nicht etwa zuerst via DNS vorgenommen, sondern – ohne Erfolg – via NDS, also über die Novell-Umgebung.

Abbildung 9.23: TraceMagic/Event-Log: Die Auflösung von DNS-Namen wie www.msn.de in IP-Adressen wird nicht etwa zuerst via DNS vorgenommen, sondern – ohne Erfolg – via NDS, also über die Novell-Umgebung.

Interessant ist, dass sich daraus eine plausible Vermutung ergibt: Der sich über die Applikation ergebende Bedarf nach Auflösung eines Ressourcen-Namens in eine IP-Adresse wird offenkundig an alle Protokoll-Stapel verteilt bzw. weitergeleitet, die der Client geladen hat. Die übliche Software-Schnittstelle, die über solche Vorgänge zu wachen hat, ist der UNC-Treiber namens MUP.SYS: UNC = Universal Naming Convention MUP = Multiple UNC Provider >>> NEW TECH

383

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

Eine der Microsoft-Fundstellen zu diesem Treiber ist diese: http://msdn.microsoft.com/archive/default.asp?url=/ARCHIVE/en-us/dnarwnet/ html/msdn_bonnet.asp

Je nach Kombination von Windows-Betriebssystem, Service-Pack, Treiberversion etc. ergeben sich auf den Client-PCs unterschiedliche Varianten, wie mit Auflösungsbegehren der Applikationen umgegangen wird. Grundsätzlich versucht Microsoft (und ggf. auch Novell), nach dem Motto »viel hilft viel« zu handeln, das heißt spätestens beim Versagen des primären Auflösungsweges werden nach und nach alle anderen möglichen Auflösungswege durchlaufen – oder aber, es werden (wie im Falle der aktuellen Beispiele) gleich alle möglichen Auflösungswege beschritten. Das kann den Vorteil haben, dass Wartezeiten entfallen, wenn wie im aktuellen Fall die Anfragen über alle Protokoll-Stapel gleichzeitig gesendet werden und wenn auf keine der anderen Varianten gewartet wird, falls eine davon bereits zum Erfolg geführt hat. Das kann aber sehr wohl den Nachteil haben, dass Wartezeiten sich massiv aufsummieren, wenn die Anfragen über die verschiedenen Protokoll-Stapel erst nach und nach durchlaufen werden. Zwar mag richtig sein, dass eine späte Auflösung besser ist als gar keine. Wenn aber der Umgang mit diesem Mechanismus gestört ist (wie im Beispiel 9.1 gezeigt), so bringt dieses »Viel hilft viel« aus der Sicht der Anwender nur noch unannehmbare Verzögerungen (»Das Netzwerk ist langsam«).

9.2.2

Das Server-Login-Script als DNS-Anfrage

In diesem Beispiel geht es wieder um DNS-Anfragen, die ihre Quelle ganz woanders haben – um Anfragen also, die weder nach Form noch Inhalt Sinn ergeben.

Abbildung 9.24: TraceMagic/HostMagic: Die Auswertung aller DNS-Vorgänge zeigt (scheinbare) DNSNamen, die unmöglich »echt« sein können; dies führt zu weiteren Untersuchungen.

384

>>> NEW TECH

Script-Reparatur per DNS

Die in Abbildung 9.24 zu sehende Liste (Ausschnitt) der DNS-Requests weist u.a. folgende, sehr zweifelhafte Einträge auf. Sie unterscheiden sich hinsichtlich ihrer Auffälligkeiten erheblich und sollen daher ausführlich besprochen werden. Darunter befindet sich eine Anfrage, die stark an die Syntax von Server-LoginScripts erinnert. Dies macht neugierig und zeigt schon beim ersten Blick, dass hier etwas nicht stimmen kann (siehe unten).

9.2.3

DNS-Anfragen nach 49

49.hicde.abc.com 49.abc.com

Diese DNS-Anfragen sind deswegen auffällig, weil DNS-Namen nicht mit Ziffern beginnen dürfen. Es werden zwar inzwischen davon hier und da Ausnahmen zugelassen, grundsätzlich aber ist dies so. Weiterhin stimmt an diesen Namen nachdenklich, dass die Zahl 49 einerseits die internationale Telefonvorwahl für Deutschland darstellt und andererseits in diesem Sinne vom Kunden innerhalb des Novell NetWare NDS-Baums verwendet wird, um die deutsche Niederlassung zu kennzeichnen. Ist das ein Zufall? Wir werden später noch sehen, dass eine nähere Betrachtung mehr als aufschlussreich ist.

Abbildung 9.25: TraceMagic/HostMagic Event-Log: Die Zahl 49 taucht als Teil der NDS-Baum-Struktur auf. Bei mangelndem Erfolg via NDS versuchen Windows-Clients zuweilen, den vermeintlichen Host namens »49« per DNS zu finden.

>>> NEW TECH

385

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

Die Verwendung der Zahl 49 als Teil der NDS-Baum-Struktur wird zugleich in verschiedenen NDS-Anfragen von Clients deutlich.

Abbildung 9.26: TraceMagic/SpiderMagic Event-Log: NDS-Anfragen zwecks Auflösung von RessourcenNamen innerhalb der NDS-Baum-Struktur

In den NDS-Anfragen von Clients taucht neben der Zahl 49 (für Niederlassung in Deutschland) auch der Server-Name LI492201 auf. Es nimmt nicht Wunder, dass dieser Server-Name auch in DNS-Anfragen auftaucht – was jedoch völlig normal bzw. korrekt ist und in diesem Zusammenhang (zunächst jedenfalls) keinen Fehler darstellt.

Abbildung 9.27: TraceMagic/HostMagic DNS-Tabelle: Der Server-Name LI492201 in den DNS-Anfragen von Clients

Die Frage, die sich hierbei stellt, ist: Werden möglicherweise NDS-Anfragen oder eben DNS-Anfragen gestellt, weil der jeweils andere Namens- bzw. Verzeichnisdienst zu keinem Erfolg führte? Die Antwort auf diese Frage ist an dieser Stelle unerheblich, da die entsprechenden Mechanismen in verschiedenen Abschnitten dieses Kapitels bereits dargestellt wurden.

386

>>> NEW TECH

Script-Reparatur per DNS

9.2.4 DNS-Anfragen nach MS2MAILSOFTWAREGW55EPCLIENTUPDATE32.DLL KOBLENZ-DE-MS2MAILSOFTWAREGW55EPCLIENTUPDATE32.DLL KOBLENZ-DE-MS2MAILSOFTWAREGW55EPCLIENTUPDATE32.DLL.hicde.abc.com KOBLENZ-DE-MS2MAILSOFTWAREGW55EPCLIENTUPDATE32.DLL.abc.com

Hier wird offenkundig mal wieder nach einer Datei gesucht (UPDATE32.DLL). Aber das ist ja inzwischen nichts Besonderes mehr (siehe Abschnitt 9.1).

9.2.5

DNS-Anfragen nach NDPS01

NDPS01.hicde.abc.com NDPS01.abc.com NDPS02.hicde.abc.com NDPS02.abc.com

Diese Anfragen sind formal durchaus korrekt. Sie dienen dank ihrer Übersicht und Kürze als Hinweis darauf, dass DNS-Clients alle verfügbaren lokalen DNS-Suffixe verwenden, um zum Erfolg zu kommen: abc.com und hicde.abc.com (beide gültig). Die absurde Variante dieses zulässigen und im Prinzip sinnvollen Verfahrens ist weiter unten zu sehen.

9.2.6

DNS-Anfragen nach SERVER

SERVER.hicde.abc.com SERVER.abc.com

Hier scheint es einerseits so, als würde ein lokaler Server via DNS gesucht. Andererseits schleichen sich Zweifel ein, ob wirklich ein Server einfach nur "SERVER" genannt wurde? Weiter unten gibt es weitere Hinweise zu diesem Rätsel.

9.2.7

DNS-Anfragen nach SERVERVOLUMEuser%username%

SERVERVOLUMEuser%username%.hicde.abc.com SERVERVOLUMEuser%username%.abc.com

Dies ist nun eine ganz neue Variante: Es ist kein normaler DNS-Name; es ist kein Datei-Name, sagen wir: Es fällt auf, dass %username% auffällig wie eine Script-Variable bzw. Umgebungs-Variable aussieht. Es ist schnell zu erkennen, dass es sich um Versatzstücke aus einem Novell NetWare Login-Script handelt. Offenkundig können Clients eine Textzeile des Server-Login-Scripts nicht korrekt verarbeiten, vermutlich hat sich ein Tippfehler eingeschlichen. Der Client-PC kommt daraufhin auf die Idee, auszuweichen und andere Wege zu gehen, um seinem »Herrchen« zu dienen. Das Ergebnis ist eine wirklich originelle DNS-Anfrage. >>> NEW TECH

387

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

9.2.8

DNS-Anfragen nach www.aol.co

www.aol.co www.aol.co.hicde.abc.com www.aol.co.abc.com

Hier ist deutlich zu erkennen, dass offenkundig ein Anwender vergessen hat, den letzten Buchstaben einzutippen. Dies führt dazu, dass der DNS-Client annimmt, es handele sich nicht um einen FQN (Fully Qualified [DNS] Name). Also nimmt der DNS-Client weiter an, es handele sich um einen Host-Namen ohne DNS-Suffix. Also entschließt sich der DNS-Client, alle ihm bekannten DNS-Suffixe (der lokalen Domains) anzuhängen. Dies führt zu den etwas skurril aussehenden, aber formal letztlich korrekten DNS-Anfragen.

9.2.9

DNS-Anfragen nach www.kieser.com

www.kieser.com www.kieser.com.hicde.abc.com www.kieser.com.abc.com

Die URL www.kieser.com ist nicht vergeben (Stand: 2002), formal jedoch handelt es sich um einen korrekten DNS-Namen bzw. um einen echten FQN (Fully Qualified Name). Dies hindert jedoch nicht an der Bildung von unsinnigen, vom Ablauf her aber zulässigen DNS-Anfragen: Auf die erste Anfrage nach www.kieser.com erhält der Client keine IP-Adresse zurück, sondern die Antwort, dass eine Auflösung nicht möglich ist. Nunmehr nimmt der DNS-Client an, dass es sich bei www.kieser.com lediglich um einen Host-Namen handelt, und hängt die bekannten lokalen Domain-Suffixe an. In diesem Fall ist das alles so gerade noch verständlich – weil nämlich die Zeichenfolge www.kieser.com nur 14 Zeichen lang ist. Warum ist das wichtig? NetBIOS-Namen sind 16 Zeichen lang, wobei Microsoft das letzte Zeichen zur Kennzeichnung des NetBIOS-Ressourcen-Typs verwendet. Das Anhängen lokaler Domain-Suffixe ist ein Teil der Migrations-Strategie von Microsoft: für den Fall nämlich, dass ein Anwender nach einem simplen NetBIOS-Namen sucht, der entsprechende Rechner inzwischen aber nur noch via DNS erreichbar ist, ist es hilfreich, wenn automatisch nicht nur nach dem 16 Zeichen langen NetBIOSNamen gesucht wird, sondern zudem nach einem DNS-Namen, der sich aus dem NetBIOS-Namen sowie einem angehängten Domain-Suffix zusammensetzt. Im vorliegenden Fall ist das formal gerade noch möglich: Es handelt sich zwar nicht um einen NetBIOS-Namen (was der DNS-Client nicht wissen kann), aber immerhin um eine Zeichenkette, die nicht länger ist als 16 Zeichen. Warum wird das Ganze hier so ausführlich erklärt? Nun, weil WindowsClients nicht nur bei unbekannten Namen mit bis zu 16 Zeichen Länge dieses Verhalten zeigen, sondern auch bei Namen, die deutlich länger sind – was offenkundig barer Unsinn ist und von den Microsoft-Programmierern offen-

388

>>> NEW TECH

Telnet-Befehle per DNS

kundig übersehen wurde. Offenkundig ist es auch bei großen Herstellern wie Microsoft ein Problem, umfassende Qualitätskontrolle bei der Erzeugung von Programm-Code zu gewährleisten.

9.3 Telnet-Befehle per DNS Quelle: Dillingen, 2002

Es gibt nichts, was es nicht gibt. Warum nicht alle Möglichkeiten nutzen, die es gibt? Also: Warum nicht auch mal Telnet-Befehle per DNS verschicken? Alles ist möglich.

9.3.1

DNS-Anfragen nach port, interfaces, configuration, admin

Das hier geschilderte Beispiel unterscheidet sich kategorisch von den vorherigen, da in diesem Falle nicht Windows-Clients die Bösen sind, sondern ein Router bzw. Layer-3-Switch (eines allseits bekannten Herstellers übrigens).

Abbildung 9.28: TraceMagic/EventFilter: Es wird auf verdächtige DNS-Namen ein Filter gesetzt, um alle Vorkommnisse dieser Art aus den Event-Logs herauszuholen.

Der Analyzer war schon mit dem Switch verbunden und lief mit (an einem unkonfigurierten Broadcast-Port), während per Telnet-Zugriff der Versuch unternommen wurde, den Mirror-Port einzurichten. >>> NEW TECH

389

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

Dabei kam es zu wirklich schönen Aufzeichnungen: Einige der Telnet-Eingaben kamen prompt auf den Switch-Ports in Form von DNS-Requests wieder heraus, und weil das als Katastrophe noch nicht reichte: Diese DNS-Requests waren sodann auch noch an die völlig unzulässige Broadcast-Adresse IP = 255.255.0.0 adressiert – was wohl mehr die Internet-IP-Subnet-Mask des Routers gewesen sein dürfte als dessen IP Subnet Broadcast Address. Man lernt ja nie aus.

Abbildung 9.29: Event-Log (gefiltert): Telnet-Eingaben (der Verfasser war live dabei!) werden in DNSRequests umgesetzt – einschließlich des mit Tippfehler gesegneten »configuration«.

9.3.2

DNS-Anfragen nach aim1.adsoftware.com.hook.com

Diese DNS-Requests stammen wieder von Windows-Clients und hier zeigt sich, wohin es führen kann, wenn man Microsoft-Programmierer auf DNS-Code los lässt. Die gar nicht mal falsche Idee, eine Migration von alten NetBIOS-Systemen zu DNS zu unterstützen, indem etwaige NetBIOS-Namen automatisch den lokalen DNS-Domain-Suffix angehängt bekommen, wird völlig pervertiert, wenn dieses Verfahren angewendet wird ■ ■

■

■

390

auf voll ausgeprägte DNS-Namen (FQN = Fully Qualified [DNS] Name), auf vermeintliche NetBIOS-Namen, die gar keine NetBIOS-Namen sein können, weil die Zeichenkette länger ist als 16 Zeichen – und NetBIOSNamen können nun mal höchsten 16 Zeichen lang sein. Selbst, wenn man mal unterstellt, dass ein DNS-FQN nicht immer sicher erkennbar ist, so muss doch wenigstens ein Microsoft-Programmierer, der an DNS herumwurstelt, in der Lage sein, bis 16 zu zählen. Nun, diese Fähigkeit scheint nicht sicher zu sein. Also – kaufen wir nur fröhlich weiter Programm-Code von dieser Baustelle! Wer noch nicht einmal abzählen kann, dass aim1.adsoftware.com ganze 19 Zeichen lang ist und eben nicht kleiner/gleich 16 Zeichen lang, wird bestimmt noch manche andere hübsche Überraschung bereithalten!

>>> NEW TECH

Telnet-Befehle per DNS

Abbildung 9.30: Original-Trace: Man beachte die IP-Empfänger-Adressen! Hierbei scheint es sich um die IP-Subnet-Mask des Routers zu handeln. Aber das macht dann ja auch schon nichts mehr.

Abbildung 9.31: Event-Log: Endlose Folgen von DNS-Versuchen, die stets gleich bleibenden Namen aufzulösen (1)

>>> NEW TECH

391

Kapitel 9 • OSI-Schichten 5 und 7: Namensdienste

Abbildung 9.32: Event-Log: Endlose Folgen von DNS-Versuchen, die stets gleich bleibenden Namen aufzulösen (2)

Abbildung 9.33: TraceMagic/HostMagic: Die Auswertung der DNS-Requests zeigt die erhebliche Menge der völlig unsinnigen und zum Teil krass unzulässigen Anfragen (aim1.adsoftware.com.hook.com).

392

>>> NEW TECH

Kapitel 10 OSI-Schicht 7: Anwendungen Im Kapitel über OSI Schicht 5 bzw. die Namensdienste war die Diagnose von Fehlern in der Umgebung von NetBIOS, WINS, DNS schnell verbunden mit Vorgängen, die von Applikationen ausgingen bzw. die auch Spuren auf dem Appl. Layer hinterließen. Es ist daher unbedingt zu empfehlen, erst das Kapitel über die Name Services zu lesen. Ohne ein klares Bild über das, was in den Namensdiensten bisweilen auf bizarrste Weise geschieht, ist ein Blick auf die Anwendungsschicht weniger empfehlenswert. Die folgenden Kapitel werden verschiedene Aspekte der Layer-7-Analyse beleuchten, mal kurz, mal lang. Sie basieren praktisch vollständig auf Ergebnissen, die mittels TraceMagic erzielt wurden – da, wie so oft, mittels normaler Analyzer wenig auszurichten ist. TraceMagic arbeitet wesentlich mit ausgedehnten Datenbanken und Tabellen, über die erst die Struktur heutiger Client/Server-Fehler sichtbar wird. Oft wird erst in der Betrachtung langer Zeiträume und tausender Client/Server-Dialoge ein bestimmtes Fehlermuster sichtbar. Insofern hat die Qualität der Analyse durchaus mit der Quantität der verarbeiteten Datenmenge zu tun. Es werden viele Befunde aus den Ergebnisdatenbanken zu sehen sein und es wird sich zeigen, wie massiv die heutige Client/Server-Kommunikation unter teilweise bizarren Fehlern leidet.

10.1 Applikations-Analyse in diesem Buch Mehrere hundert Seiten beschäftigen sich mit der Analyse von Fehlern der Anwendungs-Schicht, wobei (fast) nichts ausgelassen wird von dem, was in diesen Tagen (Stand 2002) in durchschnittlichen Netzwerken eine Rolle spielt: ■ ■ ■ ■ ■ ■

Analyse von SMB (Windows, OS/2, Samba) Analyse von NCP (Novell NetWare) Analyse von Client/Server-Fehlern in den Datei-Diensten Analyse von Login-Vorgängen (Windows, Novell NetWare) Analyse von Script-Verarbeitung durch Clients Analyse von Voice over IP (RTP, RTCP)

>>> NEW TECH

393

Kapitel 10 • OSI-Schicht 7: Anwendungen

Das meiste davon rührt unmittelbar an die brisanten Fehler dieser Tage und das meiste davon wird durch herkömmliche LAN-Analyzer in der Diagnostik kaum unterstützt. Der Leser wird Fehler sehen, die er noch niemals zu Gesicht bekam, Fehler, von denen bisher kaum vorrstellbar schien, dass sie zum Teil massenhaft auf der Leitung sind. Viele dieser Fehler sind unmittelbar dafür verantwortlich, dass Anwender sagen: »Das Netzwerk ist langsam.« Insbesondere in heterogenen Client/Server-Umgebungen (etwa: Migration von Windows 9x/Windows ME und Windows NT4 zu Windows 2000 und Windows XP oder: Novell NetWare gemischt mit MS Windows) kann es zu Problemen kommen, die mit herkömmlichen Analyzern nur schlecht sichtbar bzw. nachgewiesen werden können. Die folgenden Kapitel sind unmittelbar darauf gerichtet, die aktuellen Probleme unserer Tage nachzuweisen. Es geht weniger um akademisches Wissen als um die praktische Fähigkeit, die versteckten Fehler der heutigen Client/ServerKommunikation in den Griff zu bekommen.

10.1.1 TCP/IP und Appl. Layer Die folgenden Kapitel beleuchten die Zusammenhänge zwischen der TCP/IPAnalyse und der Diagnose der Anwendungs-Schicht. Bislang wurde bei Verwendung herkömmlicher Analyzer eher getrennt betrachtet, die Wirklichkeit der heutigen Datennetze zwingt jedoch dazu, ganzheitlich über alle Protokolle und Schichten gleichzeitig zu arbeiten. Hier wird gezeigt, wie das geht.

10.1.2 Typische Fehler in Client/Server-Dialogen Eines der Layer-7-Kapitel enthält eine Sammlung kürzerer Befunde und beleuchtet jeweils gezielt bestimmte Fehler, die heutzutage (Stand 2002) in vielen Datennetzen zu beobachten sind. Die Verbindung zu TraceMagic ist insofern unvermeidlich, als mit herkömmlichen Analyzern diese Ergebnisse entweder ■ ■ ■

gar nicht oder nur teilweise bzw. nur unvollständig oder nur bei unverhältnismäßig hohem Aufwand

erzielt werden können. Als Beleg hierfür dient die Funktion Reconstructed Files (allgemein verwendete Abkürzung: rc.files).

394

>>> NEW TECH

TraceMagic: Funktionen und Einstellungen

10.1.3 Fallstudie: Windows 95-Client Es wird vollständig nachvollzogen, was beim Booten des Windows 95-Clients vom ersten ARP-Request über das Domain-Netlogon bis zum letzten WINSRefresh geschieht. Diese Fallstudie zeigt die Netzwerk-Anmeldung Schritt für Schritt in vielen Details.

10.1.4 Fallstudie: Windows XP-Client Eines der folgenden Kapitel ist eine sehr ausführliche Fallstudie anlässlich eines auffälligen Windows XP-Clients. Diese Fallstudie zeigt von Anfang an die Herangehensweise, die eingesetzten TraceMagic-Module, die Ergebnisse samt Wertungen und Querverbindungen.

10.1.5 Fallstudie: Voice over IP und Provider-WAN Ein anderes Kapitel enthält eine Fallstudie zu Problemen mit Voice over IP (VoIP) über ein vom Kunden gemietetes Provider-WAN. Hier sind viele Aufschlüsse über das verschachtelte Wirken von Effekten aller Netzwerk-Schichten zu gewinnen. Dieses Kapitel ist gleichzeitig eine zum Teil tief in die TCP/IP-Analyse einsteigende Darstellung der Routing- und Transportrotokolle. Es wird auf verschiedene Fehler in Switches und Router eingegangen, auf Probleme mit WAN-Providern und auf die Schwierigkeit, versteckte Fehler in WANWolken nachzuweisen.

10.2 TraceMagic: Funktionen und Einstellungen Für die Applikations-Analyse ist TraceMagic mit seinem Modul SpiderMagic unerlässlich, da es zurzeit auf dem Weltmarkt kein zweites Analyse-System gibt, das diese Funktionen bieten würde.

10.2.1 SpiderMagic: TCP/IP und Appl. Layer Es stellt sich grundsätzlich die Frage, nach welcher Methode vorzugehen ist, da TraceMagic zwei verschiedene Vorgehensweisen bietet: ■ ■

Analyse des Appl. Layer (ohne TCP/IP) TCP/IP-Analyse mit parallel laufender Applikations-Analyse

Das erklärt sich wie folgt: Es gibt Fehlerabläufe, bei denen Wechselwirkungen bzw. Zusammenhänge zwischen Applikations-Funktionen (wie Datei-Diensten) und Namensdiensten sowie Routing-Fehlern und/oder TCP-Sitzungsereignissen eine Rolle spielen. Um diese Wechselwirkungen bzw. Zusammenhänge verste>>> NEW TECH

395

Kapitel 10 • OSI-Schicht 7: Anwendungen

hen zu können, ist man darauf angewiesen, sie im TraceMagic Event-Log in der Gesamtschau zu sehen. In diesem Falle ist als SpiderMagic-Funktions-Modul die TCP/IP-Analyse zu wählen und es ist die Applikations-Analyse (SMB, NCP etc.) zusätzlich zu aktivieren, damit sie parallel mitläuft. ■

■

Der Vorteil dieser Methode ist also, dass über die verschiedenen NetzwerkSchichen und Protokolle hinweg eine umfassende Analyse und Betrachtung stattfindet. Der Nachteil dieser Methode ist jedoch, dass sie wesentlich mehr Zeit in Anspruch nimmt als eine reine Layer-7-Analyse.

Abbildung 10.1: TraceMagic/TraceStatistics /TCP-UDP Port Statistics. Hier: Ausschnitt mit den fehlerhaft arbeitenden (oder von Fehlern betroffenen) Applikationen, die jeweils mit Sternchen (*) gekennzeichnet sind

396

>>> NEW TECH

TraceMagic: Funktionen und Einstellungen

Das heißt: Wenn klar ist, dass TCP/IP-Probleme ausgeschlossen werden können, wird als SpiderMagic-Funktions-Modul nur die Applikations-Analyse gewählt. Diese abgespeckte Verfahrensweise arbeitet wesentlich schneller. Die Grenzen sind jedoch fließend, denn eines der wichtigsten Diagnose-Instrumente der Applikations-Analyse ist die Auswertung der TCP-Kommunikation zwischen Client und Server. Die Ergebnisse sind in der TraceStatistics-Datenbank/ Tabelle 3 (TCP-Port Analysis) enthalten. Ein schneller Zugang zu den Meta-Ereignissen der Client/Server-Kommunikation (Sitzungsaufbau, -abbau und -abbruch, Annahmestau etc.) ist ohne diese Ergebnistabelle in vielen Fällen gar nicht möglich (siehe Abbildung 10.1). Die in Abbildung 10.1 sichtbare Darstellung zeigt nur einen winzigen Ausschnitt der Möglichkeiten, die sich aus dieser Ergebnisdatenbank gewinnen lassen. Das ganze Spektrum der Varianten wird in den folgenden Kapiteln ausgeleuchtet (siehe: WinXP-Fallstudie). Als Faustregel lässt sich sagen: ■

■

Spielt nur die LAN-Kommunikation eine Rolle, kann weitgehend darauf verzichtet werden, die Applikations-Analyse mit der TCP/IP-Analyse zu verbinden. Spielt wesentlich auch die WAN-Kommunikation eine Rolle, ist dringend angeraten, auch die TCP/IP-Analyse laufen zu lassen.

Nach einiger Kenntnis des gegebenen Netzwerkes wird sich schnell herausstellen, welche Vorgehensweise geboten ist.

10.2.2 SpiderMagic: SMB (Windows, OS/2, Samba) Es empfiehlt sich, die SMB-Analyse-Funktionen sämtlich aktiv zu lassen, da das Fehlen einzelner Funktionen den Nutzen der Gesamt-Analyse im Einzelfall stark einschränken kann. Es ist weiterhin empfehlenswert, die rc.files-Funktion parallel mitlaufen zu lassen (Rekonstruktion der via SMB übertragenen Dateien, siehe Abschnitt 10.2.6).

10.2.3 SpiderMagic: NCP (Novell NetWare) Es empfiehlt sich, die NCP-Analyse-Funktionen sämtlich aktiv zu lassen (mit Ausnahme der letzten Funktion, die sich u.a. auf NDS-Zugriffe richtet), da das Fehlen einzelner Funktionen den Nutzen der Gesamt-Analyse im Einzelfall stark einschränken kann. Es ist weiterhin empfehlenswert, die rc.files-Funktion parallel mitlaufen zu lassen (Rekonstruktion der via NCP übertragenen Dateien siehe Abschnitt 10.2.6).

>>> NEW TECH

397

Kapitel 10 • OSI-Schicht 7: Anwendungen

Abbildung 10.2: SpiderMagic/Application (Layer 7)/SMB (Server Message Block)

Abbildung 10.3: SpiderMagic/Application (Layer 7)/NCP (NetWare Core Protocol)

398

>>> NEW TECH

TraceMagic: Funktionen und Einstellungen

10.2.4 SpiderMagic: HTTP (WWW: Internet, Intranet) Die HTTP-Analyse ist vergleichsweise einfach, da die Komplexität dieses Protokolls beschränkt ist. Wichtig ist, die Auto-Detection von HTTP-Proxy-Ports zu aktivieren, wenn nicht (nicht nur) über die Standard-Ports 80 und/oder 8080 gearbeitet wird.

Abbildung 10.4: SpiderMagic/Application (Layer 7)/WWW-HTTP (mit Auto-Detection der HTTP-ProxyPorts)

10.2.5 SpiderMagic: Oracle – TNS Das vermutlich gängigste Oracle-Protokoll ist TNS (Transparent Network Substrate) über TCP-Port 1521. Diese Funktion bietet ein Decoding der wichtigsten Client/Server-Vorgänge, um sie im TraceMagic Event-Log sichtbar zu machen. Es ist wichtig, die Oracle-Analyse gemeinsam mit der TCP/IP-Analyse laufen zu lassen, da sich in 2001/2002 gezeigt hat, dass Wechselwirkungen zwischen Fehlern auf TCP/IP-Ebene und Oracle-Sitzungsabbrüchen möglich sind.

>>> NEW TECH

399

Kapitel 10 • OSI-Schicht 7: Anwendungen

Abbildung 10.5: SpiderMagic/Application (Layer 7)/Oracle TNS (Transparent Network Substrate) über TCPPort 1521

10.2.6 SpiderMagic: Reconstructed Files (rc.files) Diese Funktion rekonstruiert aus den Messdaten die Dateien, die Clients auf den LAN-Servern öffnen/lesen/schließen. Dies zielt hauptsächlich auf Dateien folgenden Typs: ■

.BAT – Batch File (Stapelverarbeitungs-Datei)

■

.CMD – Command File (Stapelverarbeitungs-Datei)

■

.CFG – Configuration File

■

.INI – Initialization File

■

.LOG – Event Log File

■

.REG – Registry File

Selbstverständlich können beliebige Dateien aus den Messdaten rekonstruiert werden, was aber nicht Sinn der Sache ist, da ja nicht Excel-Dateien mit Jahresbilanzen (oder dergleichen mehr) wiederhergestellt werden sollen. Das verstieße nun endgültig gegen den Datenschutz und wäre im Sinne der LAN-Analyse auch völlig unerheblich (von Ausnahmen abgesehen).

400

>>> NEW TECH

TraceMagic: Funktionen und Einstellungen

Das Interesse richtet sich vielmehr auf Script-Dateien, die von Clients gelesen und ausgeführt bzw. interpretiert werden. Denn hieraus ergeben sich Aktionen der Clients im LAN/WAN und umgekehrt lassen sich auf diese Weise derlei Aktionen auf Script-Befehle zurückführen. Warum scheitern hier herkömmliche Analyzer vollkommen (um nicht zu sagen: jämmerlich)? Weil herkömmliche Analyzer (deren Preise wir teilweise gar nicht mehr ansprechen wollen, weil wir sonst Tränen in die Augen bekommen) leider immer nur eine Trace-Datei zu einer Zeit auswerten können. Das ist aber auch schade, denn das Lesen von Dateien von Clients erstreckt sich nun mal häufig über mehrere Trace-Dateien bzw. über längere Zeiträume. Das ist beispielsweise bei Batch-Dateien (.BAT) so, da ein Batch-File mit 100 Zeilen vom Client hundertmal geöffnet und (jeweils teilweise) gelesen wird, da je einzelner Textzeile das Öffnen-Lesen-Schließen wiederholt wird. Und da zwischen jedem einzelnen Zugriff längere Zeit verstreichen kann, die dafür benötigt wird, den jeweiligen Befehl auszuführen (der in der Textzeile enthalten ist), kann sich das Abarbeiten einer Batch-Datei über einen längeren Zeitraum erstrecken und damit auch über mehrere Trace-Dateien. Herkömmliche Analyzer können hier nicht mithalten, ■

■

weil Filter gesetzt werden müssten, um je Trace-Datei die Datenmenge zu vermindern und somit (eingeschränkt auf einen einzelnen Client) überhaupt die Chance zu erhalten, solche Vorgänge auszuwerten, weil überhaupt keine Mechanismen dieser Art implementiert sind (von geringen Ausnahmen abgesehen; so hat z.B. Ethereal erste Ansätze hierzu, um TCP-Socket-Daten als Datenstrom sichtbar zu machen, was jedoch mit der rc.files-Funktion von TraceMagic nicht wirklich vergleichbar ist).

Man muss sich fragen, wofür die Hersteller der Edel-Analyzer eigentlich alle die Jahre bezahlt wurden. Für den Verfasser dieser Zeilen haben diese Hersteller seit Jahren längst den Bezug zur Wirklichkeit verloren. Wer diese Aussage nicht recht glauben mag, kann gerne versuchen, die in den folgenden Kapiteln beschriebenen Analysen mit seinem eigenen Werkzeug nachzubilden. Dieser Versuch wird sehr wahrscheinlich klären, wieso der Verfasser dieser Zeilen immer wieder zu seinen harten Aussagen kommt.

10.2.7 SpiderMagic: VoIP (Voice over IP) Die Analyse von Voice over IP wird sich nicht allein mit den Mitteln von TraceMagic erfüllen lassen, aber umgekehrt ist schwer vorstellbar, dass es ohne die Möglichkeiten von TraceMagic ginge. Eine besondere Rolle hierbei spielt der Umstand, dass die Sprach-Kanäle nicht mit festen UDP-Ports arbeiten, sondern über dynamisch zugewiesene UDPPorts. Es ist daher unvermeidlich, dass das Experten-System diese nicht von vornherein erkennbaren RTP-Pakete als solche identifiziert und sodann auswertet.

>>> NEW TECH

401

Kapitel 10 • OSI-Schicht 7: Anwendungen

TraceMagic bietet die Möglichkeit der Port-Auto-Detection, also der selbständigen Erkennnung der RTP- und RTCP-Ports.

Abbildung 10.6: SpiderMagic/Application (Layer 7)/Voice over IP

402

>>> NEW TECH

Kapitel 11 TCP- und Applikations-Analyse Dieses Kapitel beschreibt die verknüpfte, ganzheitliche Methode der Analyse über die Schichten 3 (Network, IP), 4 (Transport, TCP) und 7 (Application, SMB, NCP, HTTP etc.). In der Praxis stellt diese Methodik ein genauso unverzichtbares wie mächtiges Instrument der Netzwerk-Analyse ebenso wie der Client/Server-Diagnose dar.

11.1 TCP-Analyse als Teil der Applikations-Analyse Da Client/Server-Zugriffe heute fast vollständig über TCP/IP arbeiten (Banyan Vines IP, NetWare IPX, AppleTalk etc. sind heute fast vollständig ausgestorben), wäre es nahezu unverzeihlich, die Möglichkeiten nicht zu nutzen, die sich daraus ergeben. Jeder Zugriff eines Clients auf die Server wird eingeleitet, aufrecht erhalten und schließlich beendet mit TCP-Sitzungskommandos (TCP-SYN, TCP-FIN, TCP-ACK, TCP-MSS) und die Steuerung der Datenströme zwischen den Teilnehmern wird ebenfalls mit TCP-Datenflusskommandos gelenkt (TCP-ACK, TCP-PSH, TCP Window Size). Das auf Layer 7 arbeitende Applikationsgeschehen lässt sich in vielen Fällen gar nicht erklären ohne gleichzeitige Betrachtung der TCP-Abläufe (und umgekehrt). Eine ganzheitliche Sicht der Dinge ist daher unverzichtbar. TraceMagic untersucht das TCP-Verhalten in zwei getrennten Dimensionen: 1. Auf Applikationsebene (ohne Rücksicht auf beteiligte Rechner) 2. Auf Teilnehmerebene (ohne Rücksicht auf die jeweiligen Applikationen) Die verschiedenen Ebenen werden in der TraceStatistics-Datenbank in getrennten Tabellen abgebildet: 1. Applikationsebene: TraceStatistics/Tabelle 3 (TCP-Port Statistics) 2. Teilnehmerebene: TraceStatistics/Tabelle 4 (IP-Host Statistics) Für eine Verknüpfung beider Ebenen sorgt schließlich das TraceMagic EventLog, das alle Ereignisse und Auffälligkeiten nachweist. Mit der EventFilterFunktion können schnell und unkompliziert die Event-Log-Einträge nach völlig beliebigen Kriterien gefiltert werden, so u.a. eben auch TCP-Ports (Applikationsebene) oder IP-Adressen (Teilnehmerebene). Die gesamte Vorgehensweise hierzu wird in diesem Kapitel beschrieben.

>>> NEW TECH

403

Kapitel 11 • TCP- und Applikations-Analyse

11.1.1 TCP-Sitzungsverhalten der Anwendungen Die Tabelle 3 (TCP-UDP-Port Statistics) der TraceStatistics-Datenbank offenbart schnell und unkompliziert, welche Applikationen frei waren von Fehlern und welche dagegen auffällig waren oder fehlerhaft. Die TCP-Port-Statistiken sind darüber hinaus in den folgenden Text- bzw. CSV-Dateien enthalten: TM.PS.PortStatistics.TABLES.~~IP-TCP-UDP~~.TXT

Somit kann man auch unabhängig von der TraceStatistics-Datenbank die Ergebnisse sichten bzw. weiterverarbeiten (z.B. in MS Excel). Praktische Beispiele hierzu finden Sie in Abschnitt 11.2.1.

11.1.2 IP-Hosts: Teilnehmerverhalten Etwaige Erkenntnisse aus den TCP-Applikationsnachweisen können ebenso schnell und unkompliziert, wie sie gewonnen wurden, in der Tabelle 4 (IP-Host Statistics) auf die einzelnen IP-Teilnehmer heruntergebrochen werden. Außerdem sind die Daten in Text- und CSV-Dateien enthalten: TM.SM.SpiderMagic.TABLES.~~IP~~.TXT TM.SM.SpiderMagic.TABLES.~~IP~~.Hosts.CSV TM.SM.SpiderMagic.TABLES.~~IP~~.Total.CSV

Somit kann man auch unabhängig von der TraceStatistics-Datenbank die Ergebnisse sichten bzw. weiterverarbeiten (z.B. in MS Excel). Praktische Beispiele hierzu finden Sie in Abschnitt 11.2.2.

11.1.3 Event-Log: Zusammenhänge und Abläufe Die Zusammenhänge zwischen Applikationsereignissen und Host-Verhalten sind über das TraceMagic Event-Log nachvollziehbar. Fragen, die sich aus den TraceStatistics-Datenbanktabellen ergeben, werden i.d.R. hier beantwortet. TM.HIT.FRAMES.01.~.001.LOG.TXT

Praktische Beispiele hierzu finden Sie in Abschnitt 11.2.3.

11.1.4 Client-Zugriffe auf Server-Ressourcen: Erfolg und Misserfolg Alle Zugriffe von Clients auf Server-Ressourcen werden von TraceMagic in Tabellen festgehalten (SMB, NCP, HTTP). Im Falle der Windows-Dialoge werden zudem in der TraceStatistics-Datenbank, Tabelle 5, die SMB Denied Resources ausgewiesen. Diese Daten sind in den folgenden Text- und CSVDateien enthalten: TM.SM.SpiderMagic.TABLES.~~HTTP~~.WWW.Statistics.TXT TM.SM.SpiderMagic.TABLES.~~NCP~~.File.Handles.(Open.Close).TXT

404

>>> NEW TECH

Praktisches Beispiel: ICA/Citrix Metaframe

TM.SM.SpiderMagic.TABLES.~~SMB~~.File.Handles.(Open.Close).TXT TM.SM.SpiderMagic.TABLES.~~SMB~~.Error.Files.CSV

Somit kann man im Falle von SMB (Windows, OS/2, Samba) auch unabhängig von der TraceStatistics-Datenbank die Ergebnisse sichten bzw. weiterverarbeiten (z.B. in MS Excel). Für NCP und HTTP besteht diese Möglichkeit nicht (Stand 2002). Praktische Beispiele hierzu finden Sie in den Abschnitten 11.2.4 und 11.2.5.

11.2 Praktisches Beispiel: ICA/Citrix Metaframe Quelle: Köln 2002

Die folgenden Daten stammen aus einer heterogenen Windows-NetWareUmgebung, die durch Citrix Metaframe (Terminal-Server) geprägt ist. Um Missverständnisse auszuräumen: Die gelegentlich auftauchende Abkürzung »EZB« steht zwar (höchst indirekt) für den Kunden, damit ist aber nicht eine gleichnamige europäische Behörde gemeint! Wie immer gibt es auch hier keinen tatsächlichen Hinweis auf das Netzwerk, aus welchem die Daten stammen.

11.2.1 TCP-Port-Analysis (TraceStatistics, Tabelle 3) Zunächst wird in den TraceStatistics mit der Tabelle 3 (TCP-UDP-Port Statistics) gearbeitet. Sie liest sich im Prinzip wie folgt: ■ ■ ■ ■ ■ ■ ■

■ ■

Die Tabelle organisiert sich hauptsächlich mittels der TCP-UDP-Ports. Sämtliche Werte sind aus der Sicht der Port-Inhaber zu sehen. Dies sind bis Port 1024 in der Regel Server, ab Port 1025 Clients. Die einzelnen Spalten sind immer doppelt in [Rx] und [Tx] getrennt. Tx: Wie oft die Port-Inhaber eine bestimmte Aktion durchführten Rx: Wie oft an die Port-Inhaber eine bestimmte Aktion gerichtet wurde Auf diese Weise ergibt sich ein Host-übergreifendes Szenario der Applikationen insgesamt. Fragestellungen wie etwa die folgenden können einfach beantwortet werden: Bei welchen Applikationen haben die Server die Verbindung mit TCP-RST getrennt? Bei welchen Applikationen haben die Clients die Verbindung mit TCP-RST getrennt?

Die folgenden Beispiele zeigen, wie das in der Praxis durchgeführt wird.

>>> NEW TECH

405

Kapitel 11 • TCP- und Applikations-Analyse

Abbildung 11.1: TraceMagic/TraceStatistics/TCP-Port Statistics: Es wurde die Spalte »TCP ReTx [Tx]« sortiert: Wie oft haben die Port-Inhaber insgesamt TCP Retransmissions gesendet? (Hier: Port 1494; die Verursacher bei [Tx] sind: die ICA bzw. Citrix Metaframe-SERVER.)

Abbildung 11.2: TraceMagic/TraceStatistics/TCP-Port Statistics: Es wurde die Spalte »TCP ReTx [Rx]« sortiert: Wie oft haben die Port-Inhaber insgesamt TCP Retransmissions empfangen? (Hier: Port 1494; die Verursacher bei [Rx] sind: die ICA bzw. Citrix Metaframe-CLIENTS.)

406

>>> NEW TECH

Praktisches Beispiel: ICA/Citrix Metaframe

Abbildung 11.3: TraceMagic/TraceStatistics/TCP-Port Statistics: Es wurde die Spalte »TCP/RST [Tx]« sortiert: Wie oft haben die Port-Inhaber insgesamt TCP-RST Signale gesendet? (Hier: Port 158; die Verursacher bei [Tx] sind: die PC-Mail-Server)

Abbildung 11.4: TraceMagic/TraceStatistics/TCP-Port Statistics: Es wurde die Spalte »TCP/RST [Rx]« sortiert: Wie oft haben die Port-Inhaber insgesamt TCP-RST-Signale empfangen? (Hier: Port 8080; die Verursacher bei [Rx] sind: die über den HTTP-Proxy-Port arbeitenden Clients)

>>> NEW TECH

407

Kapitel 11 • TCP- und Applikations-Analyse

Ein Mausdoppelklick erzeugt die Textausgabe zum aktuell angewählten TCPPort. Dies führt zu wesentlich mehr Übersicht, da man nicht die Tabelle mit ihren vielen Spalten durchlaufen muss. Die folgenden Abbildungen zeigen die Einzelnachweise im Textformat für die Applikationen, die oben bereits mit den Werten für TCP-ReTx und TCP-RST betrachtet wurden.

Abbildung 11.5: TraceMagic/TraceStatistics/TCP-Port Statistics: Einzelnachweis in der Textausgabe für den TCP-Port 8080 (http-Proxy-Port). Es wurden 46 HTTP-Sitzungen via TCP eröffnet, davon 29 seitens der Server korrekt mit TCP-FIN, worauf nur 20 Clients korrekt mit TCP-FIN antworteten, jedoch immerhin 9 Clients mit TCP-RST. Weiterhin gab es außerhalb des TCP-FIN-Szenarios 16 Abbrüche mittels TCP-RST seitens der HTTP-Server.

408

>>> NEW TECH

Praktisches Beispiel: ICA/Citrix Metaframe

Abbildung 11.6: TraceMagic/TraceStatistics/TCP-Port Statistics: Einzelnachweis in der Textausgabe für den TCP-Port 158 (PC-Mail-Server). Es hat 30-mal seitens des oder der Server auf ein eingehendes TCP-SYN-Signal (TCP-SYN [Rx]) als unmittelbare Antwort ein TCP-RST gegeben (TCP SYN/RST [Tx]).

Eine etwas andere Herangehensweise als bei HTTP und PC-Mail wird im Falle von ICA gezeigt. Hier wird zunächst in der Tabelle 3 ganz nach rechts geblättert. Dort sind zu den Port-Nummern die Applikationsnamen angezeigt und, weit wichtiger, die Bewertung der Applikationskommunikation durch das Sternchen (*), das immer auf Fehler hinweist. Man kann alle Spalten sortieren, also auch die Statusspalte mit den Sternchen (*).

>>> NEW TECH

409

Kapitel 11 • TCP- und Applikations-Analyse

Ein Mausdoppelklick führt sodann auch hier zum Einzelnachweis für die angewählte Applikation in der Textausgabe (siehe Abbildungen 11.7 bis 11.9) .

Abbildung 11.7: TraceMagic/TraceStatistics/TCP-Port Statistics: Zunächst wird in der Tabelle ganz nach rechts geblättert, um nach Applikationsname oder Statuszeichen (*) zu sortieren.

410

>>> NEW TECH

Praktisches Beispiel: ICA/Citrix Metaframe

Abbildung 11.8: TraceMagic/TraceStatistics/TCP-Port Statistics: Einzelnachweis in der Textausgabe für den TCP-Port 1494 (ICA bzw. Citrix Metaframe). Der Error Indicator – das Sternchen (*) – weist darauf hin, dass hier Auffälligkeiten oder Fehler dokumentiert sind.

>>> NEW TECH

411

Kapitel 11 • TCP- und Applikations-Analyse

Abbildung 11.9: TraceMagic/TraceStatistics/TCP-Port Statistics: Einzelnachweis in der Textausgabe für den TCP-Port 1494 (ICA bzw. Citrix Metaframe): Es hat nur 3 TCP Retransmissions gegeben, die seitens der Server gesendet wurden, aber immerhin 62 TCP Retransmissions, die von den Clients ausgingen (bzw. die von den Servern empfangen wurden). Angesichts der Gesamtpaketzahl erscheint dies jedoch eher vernachlässigenswert.

11.2.2 IP-Host-Analysis (TraceStatistics, Tabelle 4) Nach Durchsicht der Applikationsstatistiken in Tabelle 3 gilt es nun, die auf TCP-Ebene gewonnen Erkenntnisse mittels der IP-Host-Statistiken in Tabelle 4 auf einzelne IP-Hosts herunterzubrechen. Ein ggf. wichtiger Zwischenschritt ist die Durchsicht bzw. Filterung des EventLogs, etwa mit gezielter Suche nach allen Vorgängen, die einen bestimmten TCP-Port betreffen. Ein solches Verfahren ist im folgenden Abschnitt mit Bezug

412

>>> NEW TECH

Praktisches Beispiel: ICA/Citrix Metaframe

auf den TCP-Port 158 (PC-Mail-Server) dargestellt. Auf diese Weise ist schnell festzustellen, welche IP-Teilnehmer an dem TCP-SYN-RST-Szenario auf Port 158 beteiligt sind: ■ ■

IP = 172.16.2.51 als PC-Mail-Client IP = 172.16.2.56 als PC-Mail-Server

Entsprechend einfach ist es sodann, die Statistiken dieser beiden IP-Hosts für die Protokolle IP, ICMP und TCP einzusehen. PC-Mail-Client: IP = 172.16.2.51 Die folgenden Abbildungen zeigen, wie leicht und umfassend Information zu jeglichem IP-Host aus den Tabellen herausgezogen werden kann. TraceMagic unterstützt in den TraceStatistics bis zu 65.500 IP-Hosts mit jeweils über 200 Fehler- und Ereigniszählern. Diese Leistungsfähigkeit wird nur über große Datenbanken erreicht, die allen anderen Analyzern bzw. deren Experten-Systemen völlig fehlen (siehe Abbildungen 11.10 bis 11.14).

Abbildung 11.10: TraceMagic/TraceStatistics/IP-Host Statistics: Die vorletzte Spalte zeigt den Fehlerstatus an mittels der Sternchen (*), wobei die Qualität der Fehler zunimmt, je mehr Sternchen angegeben sind. Die Quantität bzw. Menge der Vorkommnisse ist über die Spalte der »Event Packets« angegeben. Markiert ist hier die Spalte des PC-Mail-Clients IP = 172.16.2.51 (Server: IP = 172.16.2.56). Ein Mausdoppelklick auf die aktuelle Zeile erzeugt den Einzelnachweis für den aktuellen IP-Host in der Textausgabe (nächste Abbildung).

>>> NEW TECH

413

Kapitel 11 • TCP- und Applikations-Analyse

Abbildung 11.11: TraceMagic/TraceStatistics/IP-Host Statistics: Der Einzelnachweis in der Textausgabe für IP = 172.16.2.51 (1): Es besteht der Verdacht, dass IP-Pakete dieses IP-Hosts in verdrehter Reihenfolge unterwegs waren.

414

>>> NEW TECH

Praktisches Beispiel: ICA/Citrix Metaframe

Abbildung 11.12: TraceMagic/TraceStatistics/IP-Host Statistics: Der Einzelnachweis in der Textausgabe für IP = 172.16.2.51 (2): Immerhin 9 von 10 TCP-RST-Signalen insgesamt stehen im Zusammenhang mit TCP-FIN-Abläufen innerhalb von WWW- bzw. HTTP-Zugriffen und sind somit als harmlos einzustufen. Der Anteil der TCP Retransmissions ist vernachlässigenswert, die Spanne der Window-Size-Werte ist akzeptabel. – Ein Mausdoppelklick im Textfenster (oder Mausklick auf das Brillen-Symbol neben der IP-Adresse) öffnet die TraceMagic-Knowledgebase mit Host-bezogenen Erläuterungen (siehe nächste Abbildung).

>>> NEW TECH

415

Kapitel 11 • TCP- und Applikations-Analyse

Abbildung 11.13: TraceMagic/TraceStatistics/IP-Host Statistics: Der Aufruf der TraceMagic-Knowledgebase erfolgt automatisch in mit einem Filter, der nur die für den aktuellen Host IP = 172.16.2.51 festgestellten Fehler und Symptome zur Anzeige bringt. Ein Mausdoppelklick auf die Tabellenzeile öffnet das große Lesefenster (das auch zum Editieren verwendet werden kann; siehe nächste Abbildung).

Abbildung 11.14: TraceMagic/TraceStatistics/Knowledgebase: Großes Editorfenster mit den Angaben zum aktuell gewählten Datenbankeintrag (hier: TCP-Flag RST mit Datenbank-Code TCP-3-1).

416

>>> NEW TECH

Praktisches Beispiel: ICA/Citrix Metaframe

PC-Mail-Server: IP = 172.16.2.56 Nach der Betrachtung der Statistiken zu IP = 172.16.2.51 (PC-Mail-Client) fehlt noch ein Blick auf die Daten von IP = 172.16.2.56 (PC-Mail-Server), um beide Seiten der am TCP-SYN-RST-Szenario beteiligten Rechner kennen zu lernen.

Abbildung 11.15: TraceMagic/TraceStatistics/IP-Host Statistics: Der Einzelnachweis in der Textausgabe für IP = 172.16.2.56. Außer den schon bekannten TCP-RST-Replies in Antwort auf empfangene TCP-SYN-Requests zeigt sich in den Daten dieses IP-Hosts nichts Neues. Dadurch werden von Vornherein weitere Nachforschungen erspart.

Nunmehr kann wiederum der Wunsch auftreten, die hier statistisch erfassten Vorgänge in ihrem tatsächlichen Ablauf sowie in ihren Client/Server-Zusammenhängen einzusehen. Dies geschieht über das Event-Log von TraceMagic sowie über die Möglichkeit, mit der EventFilter-Funktion einzelne Inhalte des Event-Logs zu isolieren.

>>> NEW TECH

417

Kapitel 11 • TCP- und Applikations-Analyse

11.2.3 Event-Log (Abläufe und Zusammenhänge) Es wurden einige Interessante Erkenntnisse aus den Datenbanktabellen gewonnen. Nun gilt es, das Ganze anschaulich zu machen, um Abläufe und Zusammenhänge zu erkennen. PC-Mail über TCP-Port 158 In Abbildung 11.16 zeigt sich, dass außer den misslungenen Versuchen von IP = 172.16.2.51, über TCP-SYN eine PC-Mail-Sitzung aufzubauen, keine weiteren Aktionen über diesen Port gegeben sind. Interessant ist nebenbei, dass der Client nicht für jeden Versuch einen neuen TCP-Port verwendet, sondern jeweils vier Versuche über denselben Client-Port unternimmt. Das Verhalten von TCP-Treibern ist über die verschiedenen Betriebssysteme hinweg in diesem Punkt nicht sonderlich einheitlich. (Das ist kein Problem, sondern lediglich aus technischer Sicht interessant, weil hier die akademische Unterscheidung zwischen Neuversuch und Versuchswiederholung zu treffen wäre.)

Abbildung 11.16: Event-Log: Über das EventFilter-Modul wurden alle Log-Einträge herausgefiltert, die mit dem TCP-Port 158 zu tun haben.

IP = 172.16.2.56/Citrix-Server Auch, wenn in den TraceStatistics die Werte für den Host IP = 172.16.2.56 ziemlich langweilig waren, soll doch ein Blick auf die sonstigen Aktivitäten die-

418

>>> NEW TECH

Praktisches Beispiel: ICA/Citrix Metaframe

ses Rechners geworfen werden. Schnell zeigt sich, dass es sich um einen der Citrix Metaframe-Server handelt. Das macht neugierig und veranlasst den Bearbeiter, einmal nachzusehen, welche Dateien oder Ressourcen sonst noch auf dem Citrix-Server durch Clients geöffnet oder überhaupt verlangt wurden (siehe Abbildung 11.23).

Abbildung 11.17: Event-Log: Über das EventFilter-Modul wurden alle Log-Einträge herausgefiltert, die mit dem Host mit der Adresse IP = 172.16.2.56 zu tun haben. Die Kommunikation dieses Citrix-Servers erscheint unauffällig.

Name Services/Suche nach ICABROWSER Aus alter Gewohnheit sieht der Verfasser in Citrix Metaframe-Umgebungen immer nach, ob sich in den Namensdiensten etwas Auffälliges finden lässt, denn siehe, da ist es schon: Immer wieder mal kennen einige ICA-Teilnehmer den Citrix Master-Server nicht, sondern suchen ihn per NetBIOS bzw. versuchen via WINS, dessen IP-Adresse herauszufinden. Dies kann zu unerfreulichen Nebenwirkungen innerhalb der Citrix-ServerFarm führen. Dem wird dadurch entgegengewirkt, dass den Citrix-Rechnern der ICA-Master-Browser manuell bekannt gemacht wird. Die tabellarische Auswertung der Namensdienst-Statistiken ist u.a. über CSVDateien bzw. Excel-Tabellen möglich. (Siehe hierzu als Beispiel Abbildung 11.26 ff. in Abschnitt 11.2.6; die dortigen Beispiele stammen jedoch aus einem anderen Trace, nicht vom aktuellen Beispiel des Citrix Metaframe-Servers.)

>>> NEW TECH

419

Kapitel 11 • TCP- und Applikations-Analyse

Abbildung 11.18: Event-Log: In den Log-Einträgen der Name Services zeigt sich, dass der Citrix-Server mit der Adresse IP = 172.56.2.51 vergeblich versucht, die IP-Adresse (s)eines ICAMaster-Servers zu finden, dessen NetBIOS-Name ICABROWSER ist.

TCP: Abbrüche, Retransmissions Schon während der laufenden Trace-Verarbeitung waren im Event-Log allerlei sehenswerte TCP-Ereignisse aufgefallen.

Abbildung 11.19: Event-Log: Schon während der laufenden Analyse fallen die TCP-RST-Ereignisse auf TCP-Port 158 auf.

IP: Auffällig viele Paketdreher, auffällig oft Win9x Auffällig oft treten in dieser reinen LAN-Umgebung IP-Paketdreher auf. Was im WAN als Folge von Routen-Wechsel innerhalb einer vermaschten RoutingStruktur gedeutet würde, ist im LAN eher auf eine Verletzung des FIFO-Prinzips (First-In, First-Out) von Switches zu deuten – ein seltenes, aber durchaus schon nachgewiesenes Phänomen. Das Sahnehäubchen ist, dass TraceMagic sogar noch innerhalb solcher Vorgänge Hinweise auf die Windows-Versionen der betroffenen IP-Absender erkennen kann, da ein Fehler im IP-Protokolltreiber von Microsoft bis einschließlich Windows NT-4 seine eigenen Spuren hinterlässt. Wer sagt denn, dass Analyse nicht auch Freude bereiten dürfte!?

420

>>> NEW TECH

Praktisches Beispiel: ICA/Citrix Metaframe

Abbildung 11.20: Event-Log: Jede Menge Abbrüche bei WWW-Verbindungen über den HTTP-Proxy-Port 8080. Diese TCP-RST-Signale sind zwar unerfreulich, gehören aber zum normalen Alltag der Internetzugsriffe. – Unschwer zu erkennen: Bei IP = 172.16.1.2 handelt es sich um den HTTP-Proxy-Server.

11.2.4 File Services: Nachweis aller Dateizugriffe Für alle drei großen Client/Server-Protokolle (SMB, NCP, HTTP) wird durch TraceMagic eine Tabelle geführt, welche sämtliche Client-Zugriffe und ServerRückgaben nachweist. Für SMB und NCP werden die folgenden Angaben gemacht: ■ ■ ■ ■ ■ ■

Zugriffs-Code des Applikations-Protokolls (NCP, SMB) Zahl der Client-Requests Status-Code der Server (Error oder OK) Name der vom Client verlangten Ressource (Datei oder logischer Prozess) Ausgabe des File Handles durch die Server (ausgegeben an die Clients) Rückgabe des File Handles durch die Clients (dargestellt durch »...«)

Wie waren wir nur darauf gekommen, in diesem Kapitel mit der Darstellung verknüpfter TCP/IP- und Applikations-Analyse hiernach zu suchen? Ach, ja: Wir hatten im Event-Log von IP = 172.16.2.56 gesehen, dass Zugriffe auf eine Citrix Metaframe-Ressource stattgefunden hatten (siehe Abbildung 11.17). Also wollten wir doch mal sehen, was sonst noch so an Zugriffen stattgefunden hat (siehe Abbildung 11.23). >>> NEW TECH

421

Kapitel 11 • TCP- und Applikations-Analyse

Abbildung 11.21: Event-Log: Verlorene (nicht aufgezeichnete) TCP-Pakete, hier markiert als »Skipped Or Missing«, sind zu Beginn einer jeden neuen Trace-Datei (hier: Datei Nummer 2) nichts Ungewöhnliches: Ein paar Pakete gehen während des Wegschreibens der Daten auf die Festplatte des Analyzers immer verloren (abhängig von der Leistungsfähigkeit der Analyzer-Hardware).

Abbildung 11.22: Event-Log: Einige der IP-Paketdreher betreffen einwandfrei die Pakete von Win9x/ WinNT4-Stationen. Das ist nicht weiter schlimm, aber mittels eines Fehlers im IP-Protokolltreiber dieser Windows-Versionen gut erkennbar.

422

>>> NEW TECH

Praktisches Beispiel: ICA/Citrix Metaframe

Abbildung 11.23: TraceMagic/SpiderMagic: Tabelle mit dem Nachweis aller Client-Zugriffe auf ServerRessourcen einschließlich des Status- bzw. Error-Codes des Servers, des vom Server an den Client ausgegebenen File Handles (hier z.B. 0x1003) nach dem OpenFile( )Request des Clients, des CloseFile()-Befehls durch den Client (dargestellt durch »...«), mit welchem das File Handle wieder frei gegeben wird, sowie des Ressourcen-Namens.

11.2.5 SMB: Denied Resources (Zugriffsfehler) Am Ende sind wir, ausgehend von IP und TCP, endgültig am Appl. Layer und seinen spezifischen, zwischen Client und Server ablaufenden Fehlern angelangt. Zu den Höhepunkten gehören immer wieder die von Clients beantragten, aber von Servern nicht herausgegebenen Ressourcen (Dateien, Shares, Prozesse). In den Fallstudien, die Teil dieses Buches sind, wird ausführlich gezeigt, wie mit diesen Befunden in der Diagnostik umgegangen wird (siehe Abbildung 11.24). Ein Beispiel für die Verarbeitung dieser Daten in MS Excel soll ebenfalls noch gegeben werden (siehe Abbildung 11.25).

11.2.6 Name Services/Tabellen Die Namensdienste können nicht nur über die Event-Logs nachvollzogen werden (siehe Abbildung 11.18 in Abschnitt 11.2.3), sondern auch über Tabellen, die über alle Namens- bzw. Adressauflösungen statistisch Auskunft geben. Die Abbildungen zeigen die Ergebnisse eines sehr kurzen Trace, daher sind nur wenige Eintragungen zu sehen (Abbildungen 11.26 bis 11.28).

>>> NEW TECH

423

Kapitel 11 • TCP- und Applikations-Analyse

Abbildung 11.24: TraceMagic/TraceStatistics/SMB Denied Resources: Nachweis aller Ressourcen (Dateien, Shares, Prozesse), die von Clients zwar beantragt, von den Servern aber nicht herausgegeben wurden (warum auch immer).

Abbildung 11.25: TraceMagic/SpiderMagic/SMB: Die Tabelle der Fehlzugriffe auf Windows-Server via SMB in der Darstellung von MS Excel, mit sortierter Spalte »ResourceName«

424

>>> NEW TECH

Praktisches Beispiel: ICA/Citrix Metaframe

Abbildung 11.26: TraceMagic/HostMagic/Statistiken in MS Excel (1): DHCP und WINS

Abbildung 11.27: TraceMagic/HostMagic/Statistiken in MS Excel (2): WINS und NetBIOS (UDP-Port 138)

>>> NEW TECH

425

Kapitel 11 • TCP- und Applikations-Analyse

Abbildung 11.28: TraceMagic/HostMagic/Statistiken in MS Excel (3): DNS und Rx/Tx-Statistiken für MAC- und IP-Adressen

426

>>> NEW TECH

Teil III Fallstudien zu den OSI-Schichten 1 bis 7

Kapitel 12 Kapitel 13 Kapitel 14 Kapitel 15

OSI-Schicht 7: Client/Server-Dialoge OSI-Schicht 7: Fallstudie Windows 9x-Client OSI-Schicht 7: Fallstudie Windows XP-Client OSI-Schicht 7: Fallstudie Voice over IP

429 473 503 609

Kapitel 12 OSI-Schicht 7: Client/Server-Dialoge Dieses Kapitel beleuchtet in loser Reihenfolge Fehler und Szenarien, die für die Jahre 2001-2002 mehr oder weniger typisch waren und daher Aussicht darauf haben, auch im Netzwerk des geschätzten Lesers ab 2003 ihr Unwesen zu treiben. Wir bewegen uns hier nicht mehr wirklich im Bereich der Netzwerk-Analyse, sondern betreiben Windows-System-Analyse. Wir nehmen einen tiefen Einblick in die Abgründe dessen, was in den Windows-Clients bisweilen an Fehlern schlummert. In nicht wenigen Fällen spielt die gleichzeitige Anwesenheit von Microsoft- und NetWare-Treibern auf den Client-PCs eine Rolle. Die Erfahrung zeigt, dass unter ungünstigen Umständen Treiberkonflikte erhebliche Verwirrung in den Name Services sowie File Services auslösen können. Nach Genuss dieses Kapitel wird dem geneigten Leser wieder einmal mehr klar geworden sein, woher die Anwenderkommentare kommen: »Das Netzwerk ist langsam.« Es ist wirklich nicht immer unbedingt Gigabit oder Terabit oder Sonstwasbit, das zur Abhilfe dieser Zustände benötigt wird. Wenn zu einem Beispiel nur eine Quelle aufgeführt wurde, so heißt das übrigens nicht, dass es nur diese eine Quelle gäbe! Die Quellenangaben dienen wesentlich dem Verfasser, die Beispiele nachträglich zuordnen zu können. Wie immer wurden die Traces bzw. die Darstellungen mithilfe des TraceAnonModuls von TraceMagic anonymisiert, um keine vertraulichen Daten preiszugeben.

12.1 TCP-Analyse als Teil der Applikations-Analyse Da Client/Server-Zugriffe heute fast vollständig über TCP/IP arbeiten (Banyan Vines IP, NetWare IPX, AppleTalk etc. sind heute fast vollständig ausgestorben), wäre es nahezu unverzeihlich, die Möglichkeiten nicht zu nutzen, die sich daraus ergeben.

>>> NEW TECH

429

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

12.1.1 TCP-Analyse als Basis der Applikations-Analyse Jeder Zugriff eines Clients auf die Server wird eingeleitet, aufrecht erhalten und schließlich beendet mit TCP-Sitzungskommandos (TCP-SYN, TCP-FIN, TCP-ACK, TCP-MSS), und die Steuerung der Datenströme zwischen den Teilnehmern wird ebenfalls mit TCP-Datenflusskommandos gelenkt (TCP-ACK, TCP-PSH, TCP Window Size). Das auf Layer 7 arbeitende Applikationsgeschehen lässt sich in vielen Fällen ohne gleichzeitige Betrachtung der TCP-Abläufe (und umgekehrt) gar nicht erklären.

12.1.2 Bedeutung einer ganzheitlichen, verknüpften Vorgehensweise Eine ganzheitliche Sicht der Dinge ist heute unverzichtbar. Sie stellt in vielen Fällen überhaupt erst die Möglichkeit zur Verfügung, aus großen Mengen von Messdaten die ersten Ansätze zur Erkennung von Fehlern zu entwickeln, wenn weder Art, Zeitpunkt noch beteiligte Rechner des Szenarios zuvor bekannt sind. In vielen Fällen ist eine isolierte Betrachtung einzelner Protokolle oder Schichten praktisch zum Scheitern verurteilt, weil sie der Vielfalt von Fehlerursachen sowie der Komplexität von Wechselwirkungen nicht gerecht wird (genauer: gerecht werden kann). Herkömmliche LAN-Analyzer schaffen es mit ihrem Instrumentarium praktisch überhaupt nicht, auch nur die Aussicht auf eine umfassende Sicht der Dinge zu geben. Den Beweis hierfür bieten sämtliche Kapitel dieses Buches zur Applikations-Analyse jeweils auf ihre Weise. Die gesamte Vorgehensweise zur verknüpften TCP- und Applikations-Analyse ist einem eigenen Kapitel beschrieben.

12.2 Mutation von Dateinamen Zu den schönsten, weil unterhaltsamsten Fehlern gehören die Mutationen von Dateinamen durch Windows-Clients. Die folgenden Beispiele sind nicht getürkt und entsprechen absolut dem, was gemessen wurde! (Achtung: Vor Nebenwirkungen und Begleiterscheinungen ist zu warnen. Es sind vor dem Genuss unbedingt der Arzt oder der Apotheker zu befragen!)

12.2.1 SAP Login Quelle: Oldenburg (2001); München (2002); Bergkamen (2002)

Haben Sie schon mal Probleme mit Ihrem SAP-Client gehabt? Dann haben Sie heute die Chance, einen Hinweis zu erhalten, der zwar nur ein kleines Detail beleuchtet, aber doch Auskunft über die Art und Weise gibt, wie Programmierer sich die Zeit vertreiben (oder auch nicht).

430

>>> NEW TECH

Mutation von Dateinamen

Nun mal im Ernst: Die Frage muss erlaubt sein, welche Form von Qualitätssicherung die Programmierer großer Hersteller eigentlich betreiben. Vom Verfasser ist ja inzwischen bekannt, dass er gelegentlich schon mal ordentlich in die Richtung von Microsoft austeilt. Aber wir wollen gerecht sein: Auch andere Hersteller haben bisweilen ihre Probleme, Programm-Code gründlichen Tests zu unterziehen, bevor er auf die Menschheit losgelassen wird. Das vorliegende Beispiel also kommt aus der SAP/R3-Umgebung. Es zeigt, wie mehrere SAP-Clients versuchen, verschiedener Dateien habhaft zu werden, von denen sie ganz nötig annehmen, sie könnten ohne sie nicht leben. Nun: Genießen Sie die folgenden Bilder. Nur Kino ist schöner. Die Erklärung dazu folgt hinterher.

Abbildung 12.1: TraceMagic/SpiderMagic/TraceStatistics/SMB Denied Resources: Offenkundig gibt es SAP-Login-Dateien, die ein Client heftig begehrt, die aber kein Server hat, und das im Oracle-NT-Binary-Verzeichnis.

>>> NEW TECH

431

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

Die TraceStatistics der SpiderMagic-SMB-Analyse zeigen an: In vielfältiger Art wurden zwar verschiedene Formen von SAP-Login-Dateien gesucht, aber von Servern nicht herausgegeben – weil (wie man hier schon guten Mutes erraten kann) diese Dateien unter keinen Umständen existieren – und schon gar nicht im Oracle-NT-Binary-Verzeichnis \ORANT\BIN !

Abbildung 12.2: Event-Log: Erst misslingen allerlei Zugriffe auf TXT-Dateien, dann Zugriffe auf SAPLogin.exe im SAPGUI-Verzeichnis. Später dann springt der Client mit seinen Anfragen ins Oracle-NT-Binary-Verzeichnis.

432

>>> NEW TECH

Mutation von Dateinamen

Man ist also gespannt darauf, welche Vorgänge dem zu Grunde liegen und welche Clients und Server an diesem interessanten Spiel beteiligt sind. Nun, auf diese Frage kann die Antwort geliefert werden.

Abbildung 12.3: Event-Log: Die Mutationen des Dateinamens SAPLogin.exe treiben immer skurrilere Blüten: es werden immer mehr Leerzeichen vor dem .exe eingefügt.

>>> NEW TECH

433

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

Was ist hier nur geschehen? Ein hartnäckiger Kunde hat es im Herbst 2002 geschafft, endlich hierzu eine Stellungnahme von SAP zu erhalten – allerdings nur inoffiziell, denn der SAPAngestellte wollte sich, so teilte dem Verfasser sein Kunde mit, unter keinen Umständen amtlich bzw. schriftlich äußern oder gar namentlich erwähnt werden. Somit stammt die folgende Darstellung nur vom Hörensagen bzw. fußt auf den Angaben des Kunden. ■ ■

■

■

Der SAP-Client sucht nach SAPLogon.exe und findet diese Datei auch. Danach sucht der SAP-Client aus Gründen, die so genau niemand mehr kennt, zusätzlich nach SAPLogin.exe (i statt o). Es wurde vage angedeutet, dass es sich um eine »Programmierleiche« handelt, also um einen Programmieransatz, der später nicht weiter verfolgt, aber eben auch nicht herausgelöscht wurde. Ergebnis: Diese Datei gibt es nicht, sie kann nicht gefunden werden. Der Client beginnt sodann verzweifelt, dieser Datei irgendwie habhaft zu werden. Offenkundig werden mehr oder weniger zufällige Variablen oder Code-Bestandteile herangezogen, um den Dateinamen mehrfach zu mutieren. Erst nach vielen Versuchen gibt der Client auf und macht weiter wie gewohnt. Meistens ist die Verzögerung für den Anwender noch im akzeptablen Bereich (weswegen oft gar kein Anlass zu bestehen scheint, den Logon-Prozess einer Untersuchung zu unterziehen).

Nach dem Gespräch mit dem SAP-Angestellten stellte der Kunde folgende Überlegung an: Wenn der Client die Datei zwar sucht, aber nicht wirklich braucht, so könnte man ihm doch einen Dummy vorsetzen. Gesagt, getan. Es wurde eine Dummy-EXE-Datei als Fake (als ein So-tun-als-ob) in das SAPGUIVerzeichnis kopiert: Der Name entspricht dem gesuchten SAPLogin.exe und der Inhalt dieser ausführbaren Programm-Datei ist schlicht – nichts. Das Programm startet und beendet sich sofort selbst (kann sich jeder selbst programmieren). Und, siehe da: Der Client ist zufrieden und sucht nicht weiter. Das war’s. Über diesen veränderten Ablauf liegen dem Verfasser leider keine Messdaten vor, da er vergaß, den Kunden darum zu bitten. Wir glauben es mal. Dieses Beispiel schlägt insofern aus der Reihe, als hier einwandfrei bestätigt ein Fehler der Applikation vorliegt. Die folgenden Beispiele gehen in der Regel aufs Konto der Netzwerk-Treiber bzw. des Betriebssystems. Ein paar weitere Beispiele sollen die hohe Varianz dieses Fehlers zeigen bzw. die völlige Zufälligkeit der Verzeichnisse, in denen gesucht wird.

434

>>> NEW TECH

Mutation von Dateinamen

Abbildung 12.4: TraceMagic/SpiderMagic/TraceStatistics/SMB Denied Resources: Weitere Beispiele (1)/Suche im CC-Mail-Verzeichnis

Abbildung 12.5: TraceMagic/SpiderMagic/TraceStatistics/SMB Denied Resources: Weitere Beispiele (2)/Suche in einem Fremdverzeichnis

>>> NEW TECH

435

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

Abbildung 12.6: TraceMagic/SpiderMagic/TraceStatistics/SMB Denied Resources: Weitere Beispiele (3)/Suche im Lotus-Notes-Verzeichnis

12.2.2 Mutationen mit Sonderzeichen Quelle: Oldenburg (2001); Bergkamen (2002)

Die hier zu sehenden Dateinamen sind unter verschiedenen Gesichtspunkten interessant, da sich verschiedene Systematiken zeigen (siehe Abbildungen 12.7 und 12.8). (Größer-Zeichen).

436

>>> NEW TECH

Mutation von Dateinamen

Abbildung 12.7: TraceMagic/SpiderMagic/TraceStatistics/SMB Denied Resources: Verschiedene Mutationen bzw. Deformationen von Dateinamen

Abbildung 12.8: TraceMagic/SpiderMagic/TraceStatistics/SMB Denied Resources: Mutationen mit jeweils acht Sonderzeichen, die sonst nach Microsoft-Definition der Ausgabeumleitung in Scripts oder am DOS-Prompt dienen

>>> NEW TECH

437

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

\NEWS\>>>>>>>.MES Hier wird mit einem Achtfach-Platzhalter ???????? falsch umgegangen (je ein Fragezeichen nach alter DOS-Konvention für jedes Zeichen eines acht Zeichen langen Dateinamens): Jedes Fragezeichen wird ersetzt durch > (GrößerZeichen). .{stdout} Bei der Bezeichnung stdout handelt es sich um den Standard Output Channel 1 – eine in der Unix-Welt übliche Kennzeichnung des Monitors als erste Wahl für die Datenausgabe der Programme (und nicht etwa Drucker etc.). Es ist möglich, dass ein ursprünglich auf Unix programmierter Code, etwa C++, in die Windows-Welt portiert wurde und nunmehr – auf welchem Wege auch immer – diese völlig unsinnige Datei-Anfrage auslöst. \sleep"* Hier wird eigentlich nach der Datei SLEEP.* gesucht – das Asterisk lässt offen, ob es sich um .EXE, .COM, .BAT oder .CMD handelt. Der Fehler liegt darin, dass dieses Mal der Punkt verfälscht und durch ein Gänsefüßchen ersetzt wird. Da Gänsefüßchen bei Microsoft-Windows ein zulässiger Bestandteil von Pfadangaben und Dateinamen sind, können sie hier auch kein Sonderzeichen darstellen, das den Punkt etwa regulär ersetzen würde. Entsprechend antworten die Server auch mit Error-Code, weil sie nichts dergleichen herausgeben können. echo"* | ping"* | net"* Den engeren Zusammenhang haben wir eben schon anlässlich von SLEEP.* geklärt. Interessant bei den weiteren Beispielen ist etwas ganz Anderes: Es handelt sich offenkundig um Script-Befehle aus .CMD- oder .BAT-Dateien. Aufschlussreich ist nun, dass nicht allein nach den evident externen Programmen PING.EXE und NET.EXE gesucht wird, sondern auch nach ECHO, das lediglich in COMMAND.COM oder CMD.EXE als so genanntes internes Kommando existiert, das für den DOS-Prompt (Eingabeaufforderung) bzw. für Scripts (StapelverarbeitungsDateien) gedacht ist. Es ist völlig sinnlos, nach einem ECHO.COM oder ECHO.EXE zu suchen! Trotzdem lassen sich Windows-Clients nicht entmutigen und suchen dennoch. Da sie hierbei alle Verzeichnisse abklappern, die im Suchpfad angegeben sind, vergehen wieder je Kommando ein paar Mikrosekunden, die man sich hätte sparen können.

438

>>> NEW TECH

Mutation von Dateinamen

HINWEIS Hacker-Tipp: Stellen Sie ein in seiner Wirkung garantiert und ultimativ zerstörerisches Programm in eines der durchsuchten Server-Verzeichnisse, nennen Sie die ausführbare Datei ECHO.EXE (oder ähnlich, siehe oben) und Sie haben Aussicht darauf, als Hacker des Jahres ins Guinness-Buch der Rekorde zu kommen! Denn wenn schon nach diesen Kommando-Mutanten auf den Servern gesucht wird, dann wollen wir doch auch den maximalen Spaß daraus ziehen. Immer nach dem Motto: Nur der Angriff der Killer-Tomaten kann tödlicher sein!

\regedit"* Auch hier ist der engere Zusammenhang bereits geklärt. Es soll aber der Hinweis erfolgen, dass in vielen Scripts der Aufruf des REGEDIT-Programms erfolgt, um .REG-Dateien in die lokale Registry des Clients zu schießen. So weit, so gut. Wenn jedoch auf dem lokalen Rechner das REGEDIT-Programm nicht sofort gefunden wird, werden auch hierfür erst alle Verzeichnisse im Suchpfad durchlaufen – oder aber wenigstens das so genannte Current Directory, das eben auch auf einem Server liegen kann.

12.2.3 Interne Programmaufrufe des Clients als Server-Zugriffe Quelle: Karlsruhe, 2002.

Bisweilen kommt es vor, dass Windows-Clients die Befehlszeile interner Programmaufrufe als Pfadangabe für einen verfehlten Dateizugriff auf dem Server verwenden. Es ist schnell zu erkennen, dass bzw. warum diese Client-Zugriffe nicht gültig sein können: ■

■

\WINNT\system32: Hierbei handelt es sich um das lokale Windows-Systemverzeichnis der Clients. Es ist kaum anzunehmen, dass ein Client auf das Windows-Systemverzeichnis des Servers zugreift. USRMGR.EXE:.SummaryInformation:$DATA: Es ist nun einmal so, dass der Doppelpunkt in Pfadangaben nur zur Kennzeichnung eines Laufwerksbuchstabens auftreten darf, nicht aber innerhalb eines Verzeichnispfades oder eines Dateinamens.

Somit ist klar, dass schon bei rein formaler Betrachtung dieser von Clients an Server herangetragenen Verzeichnisangaben die Unzulässigkeit des Vorgangs zu erkennen ist.

>>> NEW TECH

439

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

Abbildung 12.9: TraceMagic/SpiderMagic/TraceStatistics: SMB Denied Resources (Pfadangaben von Windows-Clients)

Abbildung 12.10: TraceMagic/SpiderMagic/TraceStatistics: SMB Denied Resources (Vergrößerung)

440

>>> NEW TECH

Mutation von Dateinamen

Dieses Verhalten stellt zwar insgesamt zwischen Client und Server die Ausnahme dar, ist aber doch im Ganzen nicht so selten, wie man meinen mag. In vielen Windows-Netzwerken hat der Verfasser dieses Verhalten (so oder so ähnlich) festgestellt. Leider konnte bisher kein Hinweis erarbeitet werden, welche Ursache dieses Verhalten auslöst (und wie man es dann abstellen könnte).

12.2.4 Aus SAMPLE.TXT wird MCF-SAMPLE.TXT Quelle: Bergkamen, 2002

Wenn Dateien nicht gefunden werden, kann es durchaus sein, dass der Windows-Client es mit einem vorangestellten MCF- versucht. Hierbei scheint es sich um eine verunglückte Umsetzung eines nicht sonderlich weit verbreiteten DateiStandards zu sein, der ursprünglich 1996 von Apple eingeführt wurde, um so genannte Meta-Informationen über Dateien und Verzeichnissysteme bereitstellen zu können. Eigentlich müssten sich solche Informations-Dateien durch die Endung .mcf auszeichnen und nicht etwa durch die Voranstellung von MCF- , wie im Beispiel zu sehen. Das Beispiel zeigt, wie aus dem ursprünglichen Dateinamen BENUTZER.DIC schließlich MCF-BENUTZER.DIC wird. Einige Hinweise zum Hintergrund der MCFIdee sind im Internet unter dem folgenden Link zu finden: http://www.alvitec.ch/hotsauce/welcome.html

Abbildung 12.11: TraceMagic/TraceStatistics/SMB Denied Resources: Zuerst war versucht worden, nach BENUTZER.DIC zu suchen. Dabei bleibt es aber nicht (siehe nächste Abbildung).

>>> NEW TECH

441

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

Abbildung 12.12: TraceMagic/TraceStatistics/SMB Denied Resources: Nunmehr wird versucht, nach BENUTZER.DIC eben MCF-BENUTZER.DIC zu finden. Auch andere Dateinamen werden entsprechend mutiert.

12.2.5 Net-Install sucht nach NiAgnt32.exe.Manifest (u.a.) Quelle: München, 2002

Es ist nicht selten, dass man (in verschiedenen Netzwerken) die folgenden Abläufe (so oder so ähnlich) zu sehen bekommt. Das legt die Vermutung nahe, dass es sich hier nicht um ein Verhalten des Netzwerk-Treibers oder des Betriebssystems handelt, sondern der Anwendung auf dem Appl. Layer. Auch ein anderes Fehlerbeispiel in diesem Kapitel ergibt diesen Verdacht (siehe Abschnitt 12.3.7: »UNC-Pfade werden als Verzeichnispfade missbraucht«).

442

>>> NEW TECH

Mutation von Dateinamen

Abbildung 12.13: Event-Log: Der Client lädt erst LclFil2K.cfg, dann geht die Suche nach NiAgnt32.exe los.

Abbildung 12.14: Event-Log: Nach zunächst korrekter Suche nach NiAgnt32.exe beginnt der Client-PC (Windows XP), die Dateinamen zu mutieren.

Abbildung 12.15: TraceMagic/TraceStatistics/SMB Denied Resources: Zu Recht wurde seitens des Servers die Herausgabe von NiAgnt32.exe.Manifest und NiAgnt32.exe.Local verweigert – weil es diese Dateien nicht gibt.

>>> NEW TECH

443

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

Abbildung 12.16: Das Script-File LclFil2K.cfg (von TraceMagic über die rc.files-Funktion rekonstruiert), das letztlich die Aktivitäten von Net-Installer lenkt

12.2.6 Doppelt genäht hält besser: .EXE.PIF, .EXE.COM, .EXE.BAT ... Quelle: Bergkamen (2002); Stuttgart (2002) ...

Keine Frage: Wenn wir ausführbare Dateien suchen, wollen wir sie zuverlässig finden, und wenn ein Datei-Name den Verdacht erregt, dass die nötige DateiEndung (welche die Kennzeichnung einer ausführbaren Datei darstellt) vergessen wurde, so hängen wir diese eben an. Das scheinen sich jedenfalls ein paar Programmierer gedacht zu haben. Na, gut. Aber ob Microsoft wirklich weiß, was da geschieht, wenn eine Datei mit klarer und deutlicher .EXE-Endung weiterhin um zusätzliche Eindungen wie .PIF und .COM ergänzt wird? Zwei Beispiele sollen zeigen, wie sich der Fehler äußert: 1. Hier wird eine Datei, deren Name noch gar keine Typenendung hat, mit .EXE, .COM, .PIF etc. voll durchdekliniert. (Dass der voran stehende DateiName samt Pfad sowieso schon völlig falsch ist, passt dann auch noch gut zum Fehlerbild). Siehe Abbildung 12.17. 2. Hier wird eine ausführbare Programm-Datei, die bereits die Typenendung .EXE trägt, zusätzlich mit den anderen Endungen mutiert. Motto: Viel hilft viel! Siehe Abbildung 12.18.

444

>>> NEW TECH

Mutation von Dateinamen

Abbildung 12.17: TraceMagic/TraceStatistics/SMB Denied Resources: Einer nicht auffindbaren Datei werden verschiedene Datei-Endungen angehängt (1), um sie als ausführbare ProgrammDateien vielleicht doch noch zu finden.

Abbildung 12.18: TraceMagic/TraceStatistics/SMB Denied Resources: Einer nicht auffindbaren Datei werden verschiedene Datei-Endungen angehängt (2) , was jedoch völlig unsinnig ist angesichts des Umstandes, dass es sich ja schon um eine .EXE-Datei handelt!

Es ist wirklich kaum nachvollziehbar, was sich manchmal Programmierer bei ihren Untaten denken. Gewiss ist dieses Verhalten richtig, wenn Script-Befehle umgesetzt werden müssen, denn normalerweise erspart sich der Administrator beim Editieren von Stapelverarbeitungs-Dateien (.BAT, .CMD) die Angabe der Datei-Endungen; er gibt einfach zum Programmaufruf nur den Dateinamen an (also ohne .EXE oder .COM). Die Programmaufrufe würden scheitern, wenn das Betriebssystem keine Chance hätte, die fehlenden Datei-Endungen dazuzusetzen (was allerdings auch mit dem Asterisk * als Platzhalter ginge). Was aber schon verwundert, ist die Verlängerung völlig korrekter Dateinamen mit zusätzlichen Datei-Endungen und dieses Verhalten ist eben immer wieder mal in den Client/Server-Zugriffen zu sehen. >>> NEW TECH

445

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

12.2.7 Aus Dateien werden Verzeichnisse Quelle: Stuttgart 2002

Das folgende Beispiel zeigt neben den Namens-Mutationen zugleich die Systematik der Vorgehensweise innerhalb der TraceStatistics-Datenbank SMB Denied Resources, über die ja der Weg zur Erkenntnis führt. 1. Zuerst wird in der Tabelle die Spalte Status sortiert. Dies ergibt eine Reihenfolge gemäß der Ernsthaftigkeit der Fehler bzw. Missbildungen. Je höher der Statuswert, um so schlimmer ist der Fehler. 2. Sodann wird die Spalte File Name sortiert. Dies führt dazu, dass zum Dateinamen sämtliche Verzeichnisse sichtbar werden, in denen nach der entsprechenden Datei gesucht wurde. 3. Zuletzt wird – wenigstens bei Missbildungen – die Spalte File Extension sortiert. Hierüber kann wiederum eingesehen werden, welche Dateien von diesen Missbildungen betroffen sind.

Abbildung 12.19: TraceMagic/TraceStatistics/SMB Denied Resources: Verschiedene ausführbare Dateien wurden von .EXE zu .EXE.dir mutiert. Der Zahlenwert in der Statusspalte zeigt an, wie schwerwiegend die Missbildungen sind.

446

>>> NEW TECH

Mutation von Dateinamen

Die folgenden Abbildungen zeigen diesen Dreischritt am Beispiel der Datei DESIGNER.EXE, deren Datei-Endung (File Name Extension) von .EXE zu .EXE.dir mutiert wird.

Abbildung 12.20: TraceMagic/TraceStatistics/SMB Denied Resources: Wird die Spalte der Dateinamen sortiert, wird sichtbar, in welchen Verzeichnissen insgesamt nach designer.EXE.dir gesucht wurde.

Was dieser Unsinn soll, müsste man wohl den oder die Programmierer fragen. Es drängt sich jedoch folgende Vermutung auf: Wird ein Festplatteneintrag als Datei nicht gefunden, wird oft nach einem Verzeichniseintrag desselben Namens gesucht. Die Angabe, ob ein Name für eine Datei oder ein Verzeichnis stehen soll, gibt der Client-PC normalerweise in den Protokollen SMB, NCP, NFS an. Hier jedoch fragt man sich, ob ein Programmierer einen sehr alten Code aus den Anfangstagen der Verzeichnissysteme beibehalten hat, um einen Dateinamen als Verzeichniseintrag zu suchen. Das sind wie gesagt nur Vermutungen. Am Ende kann es uns gleich sein, woher es kommt, falsch bleibt es immer.

>>> NEW TECH

447

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

Abbildung 12.21: TraceMagic/TraceStatistics/SMB Denied Resources: Wird die Spalte der Datei-Endungen sortiert, wird sichtbar, welche Dateien von der Mutation von .EXE zu .EXE.dir betroffen sind. Die Sternchen (***) deuten die Schwere des Fehlers an (entspricht den Zahlenwerten in der Statuspalte, die hier jetzt nicht zu sehen ist).

12.3 Suche nach Dateien, die es nicht gibt Ein Spezialfall der Namens-Mutationen ist die Schöpfung von Dateinamen, die es überhaupt nicht gibt bzw. gar nicht geben kann.

12.3.1 Überall ist foo Quelle: Bergkamen 2002

Was in Deutschland oder Europa für Programmierer test als Dummy-Eintrag ist, ist für die Amerikaner foo. Woher das kommt, ist diesseits des Atlantiks nicht bekannt; aber die Wirkungen sind sichtbar. Es kommt immer wieder vor, dass Windows-Clients nach foo suchen – und die Server können nicht anders, als dieses Ansinnen jedes Mal neu zurückzuweisen.

448

>>> NEW TECH

Suche nach Dateien, die es nicht gibt

Abbildung 12.22: TraceMagic/TraceStatistics/SMB Denied Resources: Wird die Spalte [File Name] sortiert, erscheinen alle Verzeichnisse hintereinander, in denen nach foo gesucht wurde.

12.3.2 Datei-Endung, aber kein Datei-Name Quelle: Stuttgart 2002

Auch das muss es geben: Der Client sucht eine Datei-Endung (hier: .dll), aber keinen Dateinamen – die Welt wäre sonst wohl zu langweilig.

Abbildung 12.23: TraceMagic/TraceStatistics/SMB Denied Resources: Ab und an wird nur eine DateiEndung gesucht, hier: .dll.

12.3.3 %VARIABLEN% werden nicht aufgelöst Quelle: Bergkamen 2002

So genannte Umgebungsvariablen und Script-Parameter werden bisweilen nicht durch die Werte ersetzt, die eigentlich ihre Stelle einnehmen sollten. So entstehen Client-Zugriffe mit Pfadangaben, die sichtlich unsinnig sind. Oft sind es Benutzernamen, die den Verzeichnispfad ergänzen sollten, dann aber fehlen.

>>> NEW TECH

449

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

Abbildung 12.24: TraceMagic/TraceStatistics/SMB Denied Resources: Verzeichnispfade mit der Umgebungsvariablen %IDU_PATH%, die zuvor vom Client hätte umgesetzt werden müssen

12.3.4 Suche mit Datei-Verkettungen als Pfadangabe Quelle: Bergkamen 2002

Eine weitere Spezialität sind vermeintliche Pfadangaben, die tatsächlich nur aus der Verkettung verschiedener Dateinamen bestehen. Solche Anfragen können von Servern definitiv nicht konstruktiv bearbeitet werden (Abbildungen 12.25 bis 12.27).

12.3.5 Verzeichnispfade mit Laufwerksbuchstaben Quelle: Bergkamen (2002); Frankenberg (2002)

Unter gar keinen Umständen ist es zulässig, dass bzw. wenn Laufwerksbuchstaben (die ja nur relativ bzw. lokal für den Client Gültigkeit besitzen) als Teil einer Datei-Anfrage auftreten. Gleich nun, ob Applikationen oder Scripts (.BAT, .CMD) diese Anfragen veranlassen, der Netzwerk-Treiber müsste eigentlich die Syntax der Anfragen prüfen und die Übergabe solcher (vermeintlichen) Verzeichnispfade an den Server unterbinden. Der Verfasser ist im Besitz von Messdaten, in denen solche Fehlbildungen seitens der Clients höchst massiv an die Server gerichtet werden – will sagen: Es können Ausmaße erreicht werden, die man vorher nicht für möglich gehalten hätte (siehe Abbildung 12.28).

450

>>> NEW TECH

Suche nach Dateien, die es nicht gibt

Abbildung 12.25: TraceMagic/TraceStatistics/SMB Denied Resources: Verkettete Suche (1) nach IEDKCS32. DLL und CUSTOM.PIF etc. Gleichzeitig werden Variationen im Dateinamen sichtbar.

Abbildung 12.26: TraceMagic/TraceStatistics/SMB Denied Resources: Verkettete Suche (2) nach RUNDLL32.EXE, ADVPACK.DLL, C:\NTWKS40\.. mit dem zusätzlichen Fehler, dass niemals Laufwerksbuchstaben in Client-Requests auftreten dürfen, und schon gar nicht von lokalen Festplatten des Client-PCs

>>> NEW TECH

451

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

Abbildung 12.27: TraceMagic/TraceStatistics/SMB Denied Resources: Verkettete Suche (3) nach RUNDLL32.EXE u.a.m. inklusive der Zugabe, das mit /pp.pif ein interner Befehlsparameter mit Datei-Endungen versehen wird

Abbildung 12.28: TraceMagic/TraceStatistics/SMB Denied Resources: Angebliche Verzeichnispfade, deren Bestandteil Laufwerksbuchstaben bzw. lokale Verzeichnispfade des Clients sind. Dies ist unter keinen Umständen zulässig und müsste vom Netzwerk-Treiber eigentlich unterbunden werden. 452

>>> NEW TECH

Suche nach Dateien, die es nicht gibt

Siehe auch Abbildung 12.26 und Abbildung 12.27. Eine andere Variante mit völlig anderem Umfeld und anderer Struktur zeigt das zweite Beispiel. In diesem Falle ist ebenso die Syntax des Verzeichnispfades schwer gestört; man kann die Zahl der Regeln kaum zählen, die hier verletzt wurden.

Abbildung 12.29: TraceMagic/TraceStatistics/SMB Denied Resources: Die Verzeichnispfade mit \??\C:\WINNT\.. sind ebenso unzulässig wie der ganz oben zu sehende Pfad \.\NT324W05\profiles$, da der Punkt zwischen den Backslashes verboten ist.

12.3.6 Share-Pfade werden als Verzeichnispfade missbraucht Quelle: Frankenberg 2002

Dieser Fehler ist mit dem nachfolgend dokumentierten Beispiel (UNC-Pfade) eng verwandt, wird aber gesondert aufgeführt, weil er teilweise massenhaft auftritt: Der Pfad, der zum Initialisieren eines Share-Zugriffs vom Client an den Server übergeben wird (zu übergeben ist), wird in unzulässiger Weise als Verzeichnispfad einer Datei-Anfrage verwendet (wobei der sonst vorne stehende Doppel-Backslash durch einen einfachen Backslash ersetzt wird). Die Darstellung (siehe Abbildung 12.30) zeigt diese verkappten UNC-Pfade, die tatsächlich einen Festplattenpfad innerhalb des Server-Shares kennzeichnen sollen. ■

\\NT322W05\profiles$ – Dies wäre ein gültiger UNC-Name (Share).

■

\NT322W05\profiles$ – Dies ist ein unzulässiger Datei-Pfad.

Diese Fehler sind, wie gesagt, in vielen Windows-Netzwerken zu beobachten und somit sicherlich kein Zufall. Siehe hierzu auch Abschnitt 12.3.7: »UNCPfade werden als Verzeichnispfade missbraucht«.

>>> NEW TECH

453

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

Abbildung 12.30: TraceMagic/TraceStatistics/SMB Denied Resources: Hier werden vormalige UNC-Pfade, die ein Windows-Share bezeichnen, als Verzeichnispfad von Datei-Anfragen gebraucht. Die Bezeichnungen NT322W05 etc. sind Server-Namen, die im UNC-Pfad korrekt wären, hier aber keinen Sinn ergeben.

12.3.7 UNC-Pfade werden als Verzeichnispfade missbraucht Quelle: Dillingen 2002

Dieser Fehler ist deswegen so hoch interessant, weil er gravierende Mängel im tiefsten Innern von Windows-Clients offenbart: Entweder haben Applikationen die Fähigkeit/Angewohnheit, UNC-Pfade zu missbrauchen oder aber sogar Systemtreiber wie MUP.SYS (Multiple UNC Provider System Driver) sind daran beteiligt – beides ist wenig ermutigend. Das folgende Beispiel zeigt Zugriffe auf ■ ■

\\DILWDDS01.DIL.HOOK.COM\IPC$ \DILWDDS01.DIL.HOOK.COM\ni55

Der Zugriff auf das IPC$-Share ist korrekt; die Verstümmelung des UNC zum Verzeichnispfad jedoch nicht. Es bestünde natürlich die Möglichkeit, dass im initialisierten Share das Unterverzeichnis \DILWDDS01.DIL.HOOK.COM bestehen könnte. Das ist aber aus zwei Gründen abwegig: ■ ■

454

Im aktuellen Fall meldet der Server: ERROR (nicht vorhanden). Dieses Verhalten ist oft und in vielen verschiedenen Netzwerken zu beobachten. Es ist also praktisch ausgeschlossen, dass es sich um korrekte Verzeichnisangaben handeln könnte. Tatsächlich sind es deformierte UNCs, die völlig irregulär in Verzeichnispfaden verwendet werden.

>>> NEW TECH

Endlosschleifen bei Dateizugriffen

Das sind logische Fehler, die es niemals geben dürfte, weil sie die tiefsten Tiefen der Systemlogik berühren. Die Windows XP-Fallstudie enthält weitere Beispiele und Hinweise zu diesem Phänomen. Insgesamt ist zu sagen, dass bei einigen Messungen des Jahres 2002 massive Fehler dieser Art zu sehen gewesen waren. Man wird für die Zukunft beobachten müssen, ob sich ein klares Fehlerbild mit Ursachen feststellen lässt bzw. ob diese Fehler weiter zunehmen. Auch ein anderes Beispiel dieses Kapitels zeigt, dass der Net-Installer vermutlich dazu neigt, mit den File Services nicht korrekt umzugehen (siehe Abschnitt 12.2.5: »Net-Install sucht nach NiAgnt32.exe.Manifest (u.a.)«).

Abbildung 12.31: Event-Log: Erst wird mit Tree Connect zugegriffen auf \\DILWDDS01.DIL.HOOK.COM\IPC$ (zulässig) und danach erfolgt ein Dateizugriff auf \DILWDDS01.DIL.HOOK. COM\ni55 (unzulässig, sofern nicht zufällig ein Verzeichnis dieses Namens angelegt wurde).

12.4 Endlosschleifen bei Dateizugriffen Es gehört zu den zweifellos unerfreulichen Erscheinungen, wenn Clients in (fast) nicht enden wollenden Wiederholungen versuchen, Dateien zu finden, die es nicht zu geben scheint – ohne dabei aufhören zu wollen, als befänden sie sich in einer Endlosschleife. Dieses Verhalten ist dem Verfasser verblüffend häufig bei NetWare-Clients aufgefallen. Wie es scheint, können ungünstige Kombinationen von Microsoftund NetWare-Treibern zu Veränderungen des Verhaltens führen. Da auch Fehler in den Namensdiensten in auffälliger Häufigkeit bei NetWare-Clients festgestellt werden, scheinen diese Auffälligkeiten bei Dateidiensten tatsächlich in diesem Zusammenhang zu stehen.

12.4.1 Endlossuche nach denselben Dateien Quelle: Niederrhein 2001

In einer heterogenen Windows/NetWare-Umgebung klagt der Kunde über unerklärliche Effekte, Verzögerungen, Abbrüche, Wartezeiten. Es gilt wie üblich der Satz der Anwender: >>> NEW TECH

455

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

»Das Netzwerk ist langsam.« Da auch bei diesem Kunden eine moderne, leistungsfähige LAN-Technik arbeitet, kamen auch ihm Zweifel, dass es wirklich an den Switches liegen sollte oder dergleichen mehr. Eigene Messungen (mit den üblichen Analyzern) hatten nicht weitergeholfen: Keine Ethernet-Kollisionen (wie auch, da alles über Switches ging), keine Prüfsummenfehler, keine Retransmissions – eben nichts von dem, was man so aus Gewohnheit sucht (und was Analyzer so üblicherweise anzeigen). Insofern war klar, dass aller Wahrscheinlichkeit nach, wie so oft, die Ursachen in den Namens- und Datei-Diensten zu finden sein würden. In diesem Falle zeigten sich massive Fehler in den File Services. Es wurde eine Messung vorgenommen und die Messdaten wurden in TraceMagic mit dem Modul SpiderMagic untersucht. Noch während der laufenden Analyse zeigte sich im Event-Log, was da zu finden war: schier endlose Versuche, die Datei (oder das Verzeichnis) as400ncf zu finden (siehe Abbildung 12.32 ff.).

Abbildung 12.32: Event-Log: Stete Wiederholung der Suche nach as400cnf durch denselben Client mit der Adresse MAC = 0060B0:17E646 (1). Es ist ein Filter auf den Dateinamen (oder Verzeichnisnamen) as400cnf gesetzt.

456

>>> NEW TECH

Endlosschleifen bei Dateizugriffen

Abbildung 12.33: Event-Log: Stete Wiederholung der Suche nach as400cnf durch denselben Client mit der Adresse MAC = 0060B0:17E646 (2). Hier sind neben den Client-Requests auch die Server-Replies zu sehen: Der Server gibt den Error-Code 0xFF00 zurück.

Abbildung 12.34: Zur Kontrolle: Darstellung desselben Ablaufs im Analyzer (LANdecoder32, Triticom). Die Datei TM.HIT.FRAMES.01.~.001.ENF enthält alle Pakete, die mit Client/Server-Fehlern zu tun haben, aus den Original-Traces während der Analyse von TraceMagic herausgefiltert.

>>> NEW TECH

457

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

Ist erst einmal klar, wonach zu suchen ist (hier nach Erscheinungen dieser Art auf der Anwendungsschicht), gräbt man weiter – und findet eben auch mehr.

Abbildung 12.35: Event-Log: Schier endlose Suche nach der Datei SQL.INI in wechselnden (aber in der Wiederholung immer gleich bleibenden) Verzeichnissen

Abbildung 12.36: Event-Log: Schier endlose Suche nach der Datei PKZIP.PIF in wechselnden (aber in der Wiederholung immer gleich bleibenden) Verzeichnissen

458

>>> NEW TECH

Endlosschleifen bei Dateizugriffen

Abbildung 12.37: Event-Log: Schier endlose Suche nach der Ressource NE00: in wechselnden (aber in der Wiederholung immer gleich bleibenden) Verzeichnissen. Der Name der Ressource ist unzulässig, da Doppelpunkte in Dateinamen nicht erlaubt sind.

Die in Abbildung 12.35, Abbildung 12.36 und Abbildung 12.37 dargestellten Versuche von Clients, der gewünschten Datei bzw. Ressource habhaft zu werden, sind nicht nur der Quantität nach erschreckend. Im Falle der Ressource NE00: stellt das Ereignis zudem eine Qualität eigener Art dar: Da der Befehl einen Dateizugriff anzeigt, ist klar, dass der Doppelpunkt im Namen der gesuchten Ressource unzulässig ist. Es versteht sich bei Betrachtung solcher Ereignisse, dass die Arbeit der Clients verzögert wird, wenn andere Abläufe angehalten werden, weil auf die gesuchten Dateien gewartet wird. Weiterhin wird klar, dass im schlechtesten Falle – wenn nämlich sehr viele Clients gleichzeitig ein solches Verhalten zeigen – die Server nicht gerade glücklich sind über solche Belästigungen. Es muss immer für möglich gehalten werden, dass die Server-Antwortzeiten darunter leiden können. Bei einem anderen Kunden, aber in ähnlicher Umgebung, konnte der Verfasser einmal beobachten, wie es ein Windows/NetWare-Client schaffte, über 3.000mal pro Sekunde beim File-Server mit dem Befehl Get File Size nach der Größe der immer gleichen Datei zu fragen – ohne sonst irgendetwas mit dieser Datei anzufangen! Wenn das nicht nur ein Client tut, sondern womöglich hundert Clients, so muss für den Server befürchtet werden, dass seine Leistungsfähigkeit nachlässt. Insofern kann man nur froh sein, dass in den meisten Betrieben

>>> NEW TECH

459

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

inzwischen Gleitzeit herrscht: So werden die Client-PCs nämlich nicht alle zur selben Zeit gestartet. Wer hätte gedacht, dass solche Zusammenhänge einmal dem Netzwerk helfen würden!

12.4.2 Mehrfachlesen am selben Datei-Offset Quelle: Karlsruhe 2002

Es gehört zu den spannenden Client-Fehlern, in ständiger Wiederholung am selben File-Offset (an der selben Datei-Position) stets die selben Daten auszulesen. Der Server tut in diesem Falle, wie ihm geheißen: Er kann sich nicht wehren bzw. kann nicht erkennen, dass es sich um einen Akt tiefster Sinnlosigkeit handelt. In vielen Fällen wird dieses Verhalten von Windows-Clients gezeigt, auf denen neben den Microsoft-Treibern zusätzlich die NetWare-Treiber installiert sind. In vielen Fällen entfällt dieses Verhalten, wenn der NetWare-Treiber modifiziert wird (es gibt durchaus verschiedene Möglichkeiten, den Treiber zu konfigurieren), oder wenn der NetWare-Treiber vollständig entfernt wird (sofern das die Server-Landschaft zulässt).

Abbildung 12.38: Event-Log: Der Client liest mehrfach am selben Datei-Offset. TraceMagic zeigt den Widerspruch zwischen »Expected Next Offset« und »Now Requested Offset« auf.

460

>>> NEW TECH

Endlosschleifen bei Dateizugriffen

Im aktuellen Falle berichtete der Kunde jedoch, dass die Windows 2000-Clients auch nackt-und-roh (also ohne jeden weiteren Treiber, also auch ohne NetWare-Treiber) das selbe Verhalten zeigten. In einem solchen Falle muss tatsächlich von einem Fehler im Betriebssystem und/oder in der Applikation ausgegangen werden.

12.4.3 Extrem viele Zugriffe auf dieselbe Datei Quelle: Karlsruhe 2002

In diesem Beispiel wird eine Word-DOC-Datei in extrem kurzer Zeit sehr häufig hintereinander geöffnet, gelesen und geschlossen. Es gibt keinen regulären Applikationsvorgang, der das sinnvoll veranlassen könnte (siehe Abbildung 12.39).

Abbildung 12.39: TraceMagic/Statistik der Dateizugriffe: Dieselbe Datei wird in extrem kurzen Abständen stets neu geöffnet, gelesen und geschlossen.

>>> NEW TECH

461

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

12.4.4 Extreme Wiederholung derselben Datei-Anfrage Quelle: Karlsruhe 2002

Die folgenden Versuche, Datei-Informationen des Servers zu wdmaud.drw zu beziehen, übertreffen jedes noch tolerierbare Maß bei weitem.

Abbildung 12.40: Event-Log: In blinder Wut sucht der Client nach der Datei wdmaud.drw. Man achte auf die Paketnummern links: Jedes zweite Paket ist eine dieser Client-Anforderungen; die jeweils anderen Pakete (hier nicht dargestellt) enthalten die Error-Code-Rückgabe des Servers.

12.4.5 Extreme Suche nach DESKTOP.INI Quelle: Karlsruhe 2002

Es gehört bisweilen zu den Hobbys von Windows-Clients, die Datei DESKTOP. INI ■ ■

abzulegen, wo sie nicht hingehört, zu suchen, wo sie nicht ist.

Das folgende Beispiel zeigt nur ausschnittsweise die extreme Wiederholungsfreudigkeit bzw. Hartnäckigkeit, mit der hier gesucht wird.

462

>>> NEW TECH

Endlosschleifen bei Dateizugriffen

Abbildung 12.41: Event-Log: Vergebliche Versuche, DESKTOP.INI zu finden – per NetWare-NCP! (1)

Abbildung 12.42: Event-Log: Vergebliche Versuche, DESKTOP.INI zu finden – per NetWare-NCP! (2)

>>> NEW TECH

463

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

Abbildung 12.43: Event-Log: Vergebliche Versuche, DESKTOP.INI zu finden – per NetWare-NCP! (3)

12.4.6 Endlose Dateisuche in wechselnden Verzeichnissen Quelle: Karlsruhe 2002

Es gibt verschiedenste Formen der wiederholten Dateisuche. Im folgenden Beispiel werden die ewig selben drei Oracle-Verzeichnisse durchsucht – erfolglos und (fast) ohne Ende (siehe Abbildungen 12.44 und 12.45).

12.4.7 Extremes Öffnen/Lesen/Schließen von URL-Dateien Quelle: Karlsruhe 2002

In diesem Falle trifft es Dateien des Typs .URL, die von Clients in massiver Form geöffnet, gelesen und geschlossen werden, wobei jeder einzelne Vorgang dieser Art mit allen anderen identisch ist. Das Ganze ergibt keinen Sinn, scheint aber den Clients viel Freude zu bereiten. Die Screen Shots (siehe Abbildung 12.46 bis Abbildung 12.49) zeigen die wirklich auffällige Häufigkeit der Wiederholungen – ohne das ganze Ausmaß zu zeigen, weil sonst noch mehr Seiten dieses Buches mit diesen Bildern zu füllen gewesen wären. Das ganze Drama wird wieder einmal an den Aussagen der Anwender sichtbar: »Das Netzwerk ist langsam.« 464

>>> NEW TECH

Endlosschleifen bei Dateizugriffen

Abbildung 12.44: Event-Log: Die Datei mspfltrs.dll wird in verschiedenen, immer wiederkehrenden Verzeichnissen erfolglos gesucht (1).

Abbildung 12.45: Event-Log: Die Datei mspfltrs.dll wird in verschiedenen, immer wiederkehrenden Verzeichnissen erfolglos gesucht (2).

>>> NEW TECH

465

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

Abbildung 12.46: Event-Log: Der Client kommt kaum davon los, die Link-Datei Lufthansa.url stets wieder neu zu öffnen, zu lesen und zu schließen (1).

Abbildung 12.47: Event-Log: Der Client kommt kaum davon los, die Link-Datei Lufthansa.url stets wieder neu zu öffnen, zu lesen und zu schließen (2).

466

>>> NEW TECH

Endlosschleifen bei Dateizugriffen

Abbildung 12.48: TraceMagic/Tabelle der Zugriffsnachweise: Für die Client/Server-Protokolle NCP und SMB sowie für HTTP weist TraceMagic alle Dateizugriffe inklusive Request-Code, Anzahl der Server-Replies, Status bzw. Error-Code, File Handle und Dateinamen (Pfad )nach. Hier: Lufthansa.url (1).

Es waren ja nun mehrere Beispiele des Kunden aus Karlsruhe zu sehen (siehe die anderen Fälle oben). Wenn sich alle diese Verhaltensweisen aufsummieren, scheint es den Anwendern manchmal so, als ginge gar nichts mehr.

>>> NEW TECH

467

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

Abbildung 12.49: TraceMagic/Tabelle der Zugriffsnachweise: Für die Client/Server-Protokolle NCP und SMB sowie für HTTP weist TraceMagic alle Dateizugriffe inklusive Request-Code, Anzahl der Server-Replies, Status bzw. Error-Code, File Handle und Dateinamen (Pfad) nach. Hier: Lufthansa.url (2).

468

>>> NEW TECH

WWW: Fehler bei HTTP-Zugriffen

12.5 WWW: Fehler bei HTTP-Zugriffen Das Thema HTTP bzw. WWW soll hier nicht allzu lang behandelt werden, weil jeder gute Proxy-Server in der Lage ist, mit seinen Log-Dateien dieselben Auskünfte zu erteilen (oder noch weitere darüber hinaus). Da aber der LAN-Analyst nicht immer Zugriff auf die Server-Logs hat (bzw. keinen Zugriff auf die Server-Admins hat), kann es doch hilfreich sein, die wichtigsten Befunde aus den Messdaten herauszuholen.

12.5.1 Einstellungen vor Beginn der Analyse Bei der HTTP-Analyse spielt eine nicht unwesentliche Rolle, dass nicht nur über die bekannten Standard-Ports 0x0080 und 0x8080 gearbeitet wird, sondern auch über völlig frei definierte Proxy-Ports. TraceMagic kann per Auto-Detection auch die frei vergebenen Proxy-Ports erkennen und somit die HTTP-Analyse durchführen. Wer allerdings dem Programm während der Analyse der Messdaten etwas Zeit ersparen will, kann den lokalen Proxy-Port auch manuell eingeben.

Abbildung 12.50: TraceMagic/SpiderMagic: HTTP-Analyse mit aktivierter Auto-Detection etwaiger ProxyPorts, die von Port 8080 abweichen

>>> NEW TECH

469

Kapitel 12 • OSI-Schicht 7: Client/Server-Dialoge

12.5.2 Event-Log: Ablauf und Zusammenhänge Die tatsächlichen Abläufe werden bei HTTP über das Event-Log nachvollzogen. Eine Datenbank der Fehlzugriffe wie bei SMB gibt es nicht.

Abbildung 12.51: Event-Log: Verschiedene Server-Error-Codes, die im Client-Front-End nicht angezeigt werden (angezeigt wird nur 404 = Not Found)

12.5.3 Zugriffsstatistik: Nachweis aller Client-Requests und Server-Replies Wie bei SMB und NCP auch, gibt es bei HTTP den vollständigen Nachweis aller Client-Requests und Server-Replies in einer Tabelle, welche die ZugriffsCodes der Clients sowie die Status-Returns der Server ausweist. Wie sonst auch bei TraceMagic steht das Sternchen (*) für Fehler, eine Tilde (~) für Auffälligkeiten (hier im Beispiel nicht gegeben).

470

>>> NEW TECH

WWW: Fehler bei HTTP-Zugriffen

Abbildung 12.52: TraceMagic/Tabelle der Zugriffsnachweise: Alle Client-Befehle (GET, POST, HEAD etc.) samt der Server-Reaktionen, wobei das Sternchen (*) wie immer für Fehler steht

>>> NEW TECH

471

Kapitel 13 OSI-Schicht 7: Fallstudie Windows 9x-Client Quelle: Bonn 2001

Die folgende Darstellung beruht auf einer Trace-Datei mit nur 935 Frames – einer Netzwerk-Anmeldung durch einen Windows 95-Client mit der Adresse IP = 192.168.111.5. Hier geht es weniger um die Detektivarbeit der Fehlerdiagnose, sondern um die Darstellung normaler, aber so wichtiger bzw. empfindlicher Login-Prozesse. Ein typischer Ablauf von Client-Start und Client-Login sieht aus wie folgt.

13.1 DHCP/ARP: Die neue IP-Adresse Zuerst bemüht sich der Client darum, seine IP-Adresse zu bestätigen; ggf. wird eine IP-Adresse vom DHCP-Server eingeholt.

13.1.1 DHCP: Request zum Bezug der eigenen IP-Adresse BOOTP = Bootstrap Protocol DHCP = Dynamic Host Configuration Protocol Das neuere DHCP ist ein »Anhang« oder »Aufsatz« zum älteren BOOTP. Jedes DHCP-Paket enthält gewissermaßen als »Basis« oder als »Sockel« für den DHCP-Header immer jeweils noch einen BOOTP-Header. ■

■

■

■

Der DHCP-Client ruft per BOOTP/DHCP nach einem DHCP-Server, um sich eine IP-Adresse zuweisen zu lassen (IP Lease = Verleihen einer IPAdresse). In diesem DHCP-Request gibt der DHCP-Client die letzte IP-Adresse an, die ihm zugewiesen worden war (sofern es ein voriges DHCP-Lease gegeben hat. Der DHCP-Server antwortet und bestätigt entweder die alte IP-Adresse, oder er vergibt eine neue. Da der DHCP-Request per LAN-Broadcast versendet wird, können auch mehrere DHCP-Server antworten. Daher gilt noch olgendes: Der DHCP-Client bestätigt, welche IP-Adresse welchen DHCP-Servers akzeptiert wurde.

>>> NEW TECH

473

Kapitel 13 • OSI-Schicht 7: Fallstudie Windows 9x-Client

■

Die DHCP-Replies der DHCP-Server werden ebenfalls per LAN-Broadcast versendet. Damit die Zuordnung zum rufenden DHCP-Client eindeutig bleibt, enthält der BOOTP-Header (also der ältere Protokollteil) die MACAdresse des DHCP-Clients.

Es werden seitens des DHCP-Servers mehrere Parameter an den DHCP-Client ausgegeben, die mal mehr, mal weniger unerlässlich für die weitere NetzwerkKommunikation des Clients sind. Der DHCP-Server gibt dem DHCP-Client i.d.R. folgende Ressourcen bekannt: ■ ■ ■ ■ ■ ■ ■ ■

IP-Subnetz-Maske (IP Subnet Mask) IP-Adresse des fragenden DHCP Clients IP-Adresse des vorgegebenen IP-Routers (IP Default Gateway) IP-Adresse des/der WINS-Server IP-Adresse des/der DNS Server Den Namen der NetBIOS-Domain (Windows-Domain, s.u.) Den WINS-Knotentyp (WINS Node Type, s.u.) Die DHCP Lease Time (s.u.)

Für den späteren Verlauf bzw. für die Wirkung der DHCP Lease Time gilt: ■

■

■

Die vom DHCP-Server vergebene IP-Adresse hat ein Verfallsdatum, das der DHCP-Server dem DHCP-Client gleichzeitig mit der IP-Adresse bekannt gibt: die Lease Time. Der DHCP-Client hat die Aufgabe, sich nach Ablauf der halben DHCP Lease Time erneut beim DHCP-Server zu melden und das IP Lease zu bestätigen. Der DHCP-Client hat die Aufgabe, sich beim Verlassen des Netzwerkes beim DHCP-Server abzumelden. Dadurch kann die IP-Adresse wieder für die Vergabe an andere DHCP-Clients frei gegeben werden; dies jedoch wird vermieden, was in der Praxis dazu führt, dass der DHCP-Server i.d.R. bemüht ist, denselben DHCP-Clients stets dieselbe IP-Adresse zuzuweisen.

Dies ist der Ablauf im Standardfall; im Einzelfall kann das alles noch deutlich komplizierter ablaufen, so beispielsweise dann, wenn mehrere DHCP-Server ihre Dienste anbieten und/oder noch Router als DHCP Relay Agents arbeiten. Die Kontrolle hunderter oder tausender DHCP-Dialoge aus Messdaten, die einen Zeitraum von mehreren Stunden oder Tagen abbilden, ist manuell nicht mehr leistbar. Hier ist eine automatische Auswertung unausweichlich.

474

>>> NEW TECH

DHCP/ARP: Die neue IP-Adresse

Abbildung 13.1: BOOTP/DHCP-Dialog zwischen DHCP-Client (IP = 0.0.0.0) und DHCP-Server (IP = 192.168.111.1)

Abbildung 13.2: Dasselbe BOOTP/DHCP-Paket noch einmal, aber nun mit Anzeige der MAC-Adressen: Der Client-Request wird an die LAN-Broadcast-Adresse geschickt.

>>> NEW TECH

475

Kapitel 13 • OSI-Schicht 7: Fallstudie Windows 9x-Client

Abbildung 13.3: TraceMagic/HostMagic/; die vom DHCP-Server zurückgegebenen Werte für: IP Subnet Mask, Client IP Address, IP Router (Default Gateway), DNS Server, WINS-Server, WINS Node Type (Knotentyp) (HostMagic/SingleHosts-Tabelle in MS Excel)

13.1.2 ARP: zur Verifikation der IP-Adresse (»Gratuitious ARP«) ARP = Address Resolution Protocol IP-Adressen müssen eindeutig sein. Was nun, ■

■

wenn nicht alle IP-Teilnehmer mit DHCP arbeiten – wenn also alte Rechner mit fest eingestellter IP-Adresse mit DHCP-Clients um die selbe IP-Adresse konkurrieren, wenn es Defekte im DHCP-System und daher mehrfach vergebene IP-Adressen gibt?

Ein IP-Teilnehmer tut gut daran, seine eigene IP-Adresse als einmalig und eindeutig zu verifizieren. Dies geschieht durch eine besondere Form des ARPRundrufs. ■

■

476

Der IP-Client sendet mehrere ARP-Requests gewissermaßen an sich selbst: Die MAC Destination Address ist die LAN-Broadcast-Adresse MAC = FFFFFF.FFFFFF; die gesuchte IP-Adresse ist die eigene IP-Adresse. Antwortet ein anderer IP-Client auf diesen ARP-Request, so ist klar, dass die IP-Adresse bereits vergeben bzw. in Verwendung ist. In diesem Falle gibt

>>> NEW TECH

WINS und GETDC

■

der zweite, zuletzt ins Netz gestartete IP-Client eine Fehlermeldung aus und bricht die Initialisierung des IP-Treibers ab. Antwortet kein anderer IP-Client (was der Regelfall ist), gilt die IP-Adresse als bestätigt und verwendbar.

Erst jetzt kann der IP-Teilnehmer als gleichwertiges Mitglied des IP-Netzwerkes auftreten.

Abbildung 13.4: Die Verifikation der eigenen IP-Adresse mittels ARP-Request: Einmaligkeit bzw. Eindeutigkeit müssen durch Abwesenheit eines ARP-Replys bestätigt werden.

Die (vermeintlich) gesuchte MAC-Adresse eines möglicherweise schon vorhandenen Konkurrenten bzgl. der eigenen IP-Adresse ist in der Darstellung des Analyzers in Abbildung 13.4 die Target HW Address und da sie nicht bekannt ist (wie auch!), ist dieses Feld auf 0x000000.000000 gesetzt.

13.2 WINS und GETDC 13.2.1 WINS: Anmeldung am WINS-Server Jeder Windows-Rechner mit Win9x, WinME und WinNT4 verwendet das NetBIOS-Protokoll zur Identifikation von Netzwerk-Teilnehmern mittels

>>> NEW TECH

477

Kapitel 13 • OSI-Schicht 7: Fallstudie Windows 9x-Client

NetBIOS-Namen. NetBIOS-Namen können an folgende Netzwerk-Ressourcen vergeben werden: ■ ■ ■ ■ ■

User Name Computer Name Workgroup Name Domain Name (= Domain Controller Name) Share Name (= Freigabe)

Jeder NetBIOS-Rechner ist selber dafür verantwortlich, ■ ■ ■ ■

alle anderen NetBIOS-Teilnehmer bzw. NetBIOS-Ressourcen zu kennen, zu jedem NetBIOS-Namen die zugehörige Adresse zu haben (MAC, IPX, IP; je Protokoll-Stapel), die Eindeutigkeit der NetBIOS-Namen zu verifizieren, sämtliche Angaben in einer Tabelle zu führen und zu pflegen: Dies geschieht im NetBIOS Name Cache, auch bekannt als Netzwerk-Umgebung.

Bei den älteren Protokoll-Stapeln NetBEUI und NWLink (NetWare IPX) läuft dies über Broadcasts oder über eine einfache Vorform des Name Servers, den Master-Browser. Bei dem aktuellen Protokoll-Stapel NetBT (NetBIOS over TCP/IP) pflegt der zentrale Name-Server das NetBIOS Name Cache (also die Liste aller NetBIOSNamen und -Ressourcen). Dies ist der WINS-Server. Damit der WINS-Server die vollständige Tabelle aller NetBIOS-Ressourcen führen kann, müssen sich sämtliche NetBIOS-Teilnehmer bei ihm anmelden (und am Ende wieder abmelden): dies ist die WINS-Registration. Um die Eindeutigkeit und Gültigkeit von Tabelleneinträgen sicherstellen zu können, wird die Anmeldung von WINS-Clients am WINS-Server von letzterem unter Angabe einer WINS Lease Time bestätigt. Wie bei DHCP auch hat der WINS-Client die Pflicht, sich nach Ablauf der halben WINS Lease Time beim WINS-Server zu melden und sich die weitere Gültigkeit der Anmeldung bestätigen zu lassen. Mögliche Störungen/mögliche Abhilfe Falls sich eine hinreichend große Zahl von NetBIOS-Teilnehmern nicht am WINS-Server bekannt macht, »lernen« die verbleibenden WINS-Clients, dass der WINS-Server nicht alles »weiß« und dass sie besser das Führen der NetBIOS-Tabelle sowie deren Verifikation selber in die Hand nehmen. Die Folge davon ist ein Ausweichen auf DNS, auf die LMHOSTS-Datei oder auf LAN-Broadcasts. Dies kann zu schweren Störungen führen, weil jeder Vorgang Wartezeiten mit sich bringt. Dies führt am Ende zum bekannten Satz der Anwender: »Das Netzwerk ist langsam.«

478

>>> NEW TECH

WINS und GETDC

Wenn NetBIOS-Rechner nach NetBIOS-Ressourcen suchen, die im Netz nicht (mehr) aktiv sind, sollten sog. Pseudo-Einträge am WINS-Server manuell vorgenommen werden: Den dauerhaft inaktiven, aber weiterhin gesuchten NetBIOS-Namen wird dann eine Dummy IP Address zugewiesen (irgendeine nicht verwendete IP-Adresse). Voraussetzungen für den WINS-Betrieb Die Client-PCs müssen »wissen«, dass sie mit WINS arbeiten sollen. Dies wird entweder lokal in der Systemsteuerung/Netzwerk eingetragen (was einen Registry-Eintrag bewirkt) oder es wird via DHCP (s.o.) mitgeteilt. Ebenso muss bekannt sein (lokale Einstellung oder DHCP), welche IP-Adresse der WINSServer hat (oder die WINS-Server, da es mehrere geben kann). Wichtig ist die Zuweisung des sog. WINS Node Type, eines WINS-Knotentyps, dessen Wert beschreibt, wie die Auflösung von NetBIOS-Namen zu IP-Adressen via WINS gehandhabt werden soll: Knotentyp

Wirkung/Vorgehensweise

WINS Node Type 0

nicht vergeben/wie »Broadcast Node«: Es werden immer Broadcasts gesendet.

WINS Node Type 1

»Broadcast Node«: Es werden immer Broadcasts gesendet.

WINS Node Type 2

»Peer-to-Peer Node«: Es wird immer der WINS-Server direkt gefragt.

WINS Node Type 4

»Mixed Mode«: Erst Broadcasts (Typ 1), danach ggf. WINS-Server fragen (Typ 2)

WINS Node Type 8

»Hybrid Mode«: Erst WINS-Server fragen (Typ 2), danach ggf. Broadcasts (Typ 1)

Tabelle 13.1: Die WINS-Knotentypen und ihre Wirkung

Wird der Knotentyp falsch angegeben, kann dies erhebliche Folgen für das NetBIOS-System haben, bis hin zu Session-Abbrüchen oder Broadcast-Stürmen. (siehe: Networker’s Guide, Erste Auflage (April 2000), Abschnitt »WINS«). Der Hergang beim Booten des Client-PCs ist darum wie folgt: ■

■

Der WINS-Client ruft den WINS-Server unter dessen IP-Adresse. Die IPAdresse des WINS-Servers wird dem Client für gewöhnlich via DHCP durch den DHCP-Server bekannt gegeben. Der WINS-Client registriert sich beim WINS-Server wenigstens unter Bekanntgabe folgender Ressourcen: NetBIOS User Name und NetBIOS Domain Name.

>>> NEW TECH

479

Kapitel 13 • OSI-Schicht 7: Fallstudie Windows 9x-Client

■

■ ■

Der WINS-Server bestätigt jeweils die Meldungen und trägt die NetBIOSNamen je Ressourcentyp in seiner NetBIOS-Tabelle (NetBIOS Name Cache) ein. Der WINS-Server gibt mit der Bestätigung eine Lebensdauer für die Registration bekannt: WINS Lease Time. Der WINS-Client muss sich nach Ablauf der halben WINS Lease Time erneut melden und sich die Gültigkeit der eigenen Anmeldung erneut bestätigen lassen.

In Abbildung 13.5 ist der WINS Registration Request des Clients zu sehen.

Abbildung 13.5: Der WINS-Client namens CLIENT1 gibt seinen NetBIOS-Namen sowie seine Adresse I P = 192.168.111.152 bekannt. Das WINS-Paket ist als Registration-Request markiert.

Der WINS-Client namens CLIENT1 gibt seinen NetBIOS-Namen sowie seine Adresse IP = 192.168.111.152 gegenüber dem WINS-Server bekannt, damit dieser beides prüfe (ob noch frei oder schon durch Dritte blockiert) und sodann antworten möge (siehe Abbildung 13.5). Der WINS-Server bestätigt Namen und Adresse (siehe Abbildung 13.6).

480

>>> NEW TECH

WINS und GETDC

Abbildung 13.6: Der WINS-Server bestätigt Namen und Adresse. Das WINS-Paket ist als RegistrationResponse markiert.

13.2.2 WINS: Abfragen der IP-Adresse des PDC Jede NetBIOS-Domain (Windows-Domain) hat einen Primary Domain Controller (PDC); dieser ist bei Ausfall ersetzbar durch den Backup Domain Controller (BDC). Dieser bestätigt den Windows-Clients, ■ ■ ■

dass sie zugelassene Teilnehmer der Domain sind, dass sie Zugriffsrechte auf die Daten der Domain haben, dass sie mit anderen Domain-Teilnehmern kommunizieren dürfen.

Um sich am PDC anmelden zu können, muss der Domain-Client die IP-Adresse des PDC kennen. Da der WINS-Client den Namen der Domain kennt, an der er sich anmelden soll, geschieht Folgendes: ■ ■

Der WINS-Client fragt den WINS-Server nach der IP-Adresse, die dem Domain Name zugeordnet ist. Der WINS-Server gibt darauf hin die IP-Adresse des PDC (Primary Domain Controller) zurück.

Jetzt kann der Domain-Client die Anmeldung vollziehen.

>>> NEW TECH

481

Kapitel 13 • OSI-Schicht 7: Fallstudie Windows 9x-Client

13.2.3 SMB: GETDC-Request zur Bestätigung des PDC Bevor das eigentliche NetLogon beginnt, muss der Domain-Client erst einmal verifizieren, dass hinter der IP-Adresse, die vom WINS-Server zur Domain erfragt wurde, wirklich der PDC steht (und nicht ein anderer Rechner). Im weitesten Sinne kann das so formuliert werden: Der vermeintliche PDC wird gefragt, ob er denn auch PDC ist. Dies geschieht mit einem Funktionsaufruf des Protokolls SMB, genannt: GETDC = Get Domain Controller Falls der solcherart angesprochene Rechner tatsächlich der PDC ist, wird er mit folgenden Angaben antworten: ■ ■

NetBIOS-Name des PDC (ANSI-Zeichensatz und UniCode-Zeichensatz) NetBIOS-Name der Domain

Im Hergang bedeutet dies: ■ ■

Der Domain-Client fragt per SMB-GETDC, ob der vermeintliche PDC tatsächlich auch der PDC ist. Der Domain-Controller antwortet per SMB-GETDC, dass er tatsächlich der PDC der Domain ist.

Der GETDC-Funktionsaufruf wird erweitert um eine eindeutige ID etwa zu GETDC197; diese ID wird vom PDC in der Antwort erneut angeführt.

Abbildung 13.7: Der SMB-GETDC-Request des Domain-Clients

482

>>> NEW TECH

WINS und GETDC

Abbildung 13.8: Der SMB-GETDC-Response des Domain-Controllers; der RPC gibt darin seinen NetBIOS-Namen bekannt (hier: NT_SERVER_1).

13.2.4 WINS: Abfragen der IP-Adresse des PDC Jetzt wird der Domain-Client per WINS beim WINS-Server die IP-Adresse des PDC erfragen (und in aller Regel auch erhalten) – genauer: Er wird die IP-Adresse des NetBIOS-Teilnehmers mit dem Namen NT_SERVER_1 abfragen. Daraus ergibt sich die Frage: »Aber hallo! Hat nicht eben der Client bereits per IP mit dem PDC gesprochen?« Richtig, trotzdem muss die IP-Adresse des PDC erneut abgefragt bzw. bestätigt werden. Gründe: ■ ■

Ein Rechner könnte IP-Spoofing betreiben und so tun, also ob er der PDC wäre, ohne es zu sein. Sehr viel wahrscheinlicher aber ist das Szenario, dass der PDC per Broadcast gesucht wird, wenn bzw. weil die IP-Adresse der Domain nicht bekannt ist (was in diesem Beispiel nicht der Fall ist). Dies wäre z.B. möglich, wenn der WINS-Server nicht verfügbar ist und somit die IP-Adresse der Domain (bzw. des PDC) nicht per WINS erfragt werden kann; in diesem Falle würde der SMB-GETDC-Befehl per Broadcast verschickt und damit würden alle NetBIOS-Teilnehmer gefragt, wer sich als PDC ausweisen kann.

>>> NEW TECH

483

Kapitel 13 • OSI-Schicht 7: Fallstudie Windows 9x-Client

Abbildung 13.9: WINS-Request zur Auflösung des PDC-Namens NT_SERVER_1 in dessen IP-Adresse

Abbildung 13.10: WINS-Reply des WINS-Servers unter Rückgabe der IP-Adresse des PDC

484

>>> NEW TECH

SMB: NETLOGON

Der Hergang im aktuellen Beispiel ist wie folgt: Der Domain-Client fragt den WINS-Server, um zum NetBIOS-Namen des PDC (erfahren via SMB-GETDC) dessen IP-Adresse zu erfahren. Der WINS-Server gibt die IP-Adresse des PDC zurück. Jetzt erst kann sich der Domain-Client am PDC regulär per NetLogon anmelden. Die Ergebnisse der WINS-Abfragen können mittels TraceMagic automatisch ermittelt und in Tabellenform eingesehen bzw. weiterverarbeitet werden.

Abbildung 13.11: TraceMagic/HostMagic: Auswertung der Name-Service-Dialoge in einer MS Excel-Tabelle

13.3 SMB: NETLOGON Das NetLogon läuft auf verschiedenen Ebenen ab: Erst über TCP, dann NetBIOS, dann SMB.

13.3.1 OSI-Schicht 4: TCP-SYN Zunächst wird eine TCP-Verbindung aufgebaut: ■

Client sendet TCP-SYN (Synchronize).

>>> NEW TECH

485

Kapitel 13 • OSI-Schicht 7: Fallstudie Windows 9x-Client

■ ■

Server sendet TCP-SYN-ACK (Synchronize/Acknowledge). Client sendet TCP-ACK (Acknowledge).

Im Zuge dieses TCP Three-Way-Handshake werden ausgehandelt: ■

■

TCP-MSS/Maximum Segment Size: Die TCP-MSS gibt die maximale Nutzdatengröße in Abhängigkeit zum verwendeten LAN-Medium an, etwa 1.460 Oktette bei Ethernet (das sind: 1.500 Bytes Ethernet-Nutzfracht abzüglich der Länge des IP-Headers von 20 Oktetten abzüglich der Länge des TCPHeaders von 20 Oktetten = 1.460 Oktette). TCP Send Sequence Number/Receive Acknowledge Number: Diese Zufallszahlen markieren den logischen Nullpunkt im Sende-Offset (Sendeposition) und im Empfangs-Offset (Empfangsposition).

Wollte (kann) ein TCP-Teilnehmer eine angefragte TCP-Session nicht annehmen, würde mit TCP-RST (Reset = Abbruch) geantwortet.

Abbildung 13.12: Das TCP-SYN des Clients unter Angabe der TCP-MSS = 1460 (Ethernet) sowie der eigenen SeqNo = 65542

486

>>> NEW TECH

SMB: NETLOGON

Abbildung 13.13: Das TCP-SYN-ACK des Servers unter Angabe der TCP-MSS = 1460 sowie der eigenen SeqNo = 110478651 sowie unter Bestätigung der SeqNo der Gegenstelle als AckNo = 65543 (= 65542+1). Da die AckNo immer die Aufforderung darstellt, ab dem genannten Offset zu senden, wird der Bestätigung immer ein +1 hinzu gerechnet.

13.3.2 OSI-Schicht 5: NetBIOS Session Request Nach Etablieren der TCP-Sitzung wird mit dem NetBIOS-Protokoll auf dem Session Layer eine Sitzung etabliert. Zu alten NetBIOS-Zeiten Anfang der 80-er Jahre, als es noch keinen Domain-Controller zur Bestätigung von Benutzern und Rechten gab, war damit bereits alles getan. Mit der Einführung von NetBEUI (NetBIOS Extended User Interface) bzw. von SMB (Server Message Block) als der eigentlichen Protokollebene, auf der Client und Server miteinander handeln konnten, ist seit Mitte der 80-er Jahre zusätzlich ein SMB-Handshake nötig (s.u.). Der Hergang im aktuellen Beispiel ist wie folgt: ■ ■

NetBIOS-Request Type 0x81/Antrag auf Sitzung unter Nennung von Client-Name und PDC-Name NetBIOS-Response Type 0x82/Positive Acknowledge = Annahme bzw. Bestätigung der Sitzung

Die Darstellung der NetBIOS-Namen als ANSI/ASCII-Code scheitert (siehe den Hex-Dump des Analyzers in Abbildung 13.14), da hier der CIFS-Zeichensatz verwendet wird. >>> NEW TECH

487

Kapitel 13 • OSI-Schicht 7: Fallstudie Windows 9x-Client

Abbildung 13.14: NetBIOS_Session_Request des Clients. Die NetBIOS-Namen sind im Zeichensatzformat CIFS kodiert und daher im Hex-Dump nicht im Klartext lesbar!

Abbildung 13.15: NetBIOS Session Accept des Servers (Annahme bzw. Bestätigung der Sitzung)

488

>>> NEW TECH

SMB: NETLOGON

13.3.3 OSI-Schicht 7: SMB Verify Dialect Bevor nun endlich die eigentliche Client/Server-Sitzung im SMB-Protokoll eingerichtet werden kann, müssen sich die beiden Teilnehmer überhaupt erst mal darauf verständigen, ob und wie sie sich unterhalten können. Der Client bietet im Klartext alle SMB-Dialekte an, die er sprechen kann: ■ ■ ■ ■ ■ ■ ■ ■

PC Network Program 1.0 (IBM) Xenix Core (Microsoft) Microsoft Networks 1.03 LanMan 1.0 (Microsoft) Windows for Workgroups 3.1a LM1.2 (LanManager for Unix) LanMan 2.0 (Microsoft) NT LM 0.12 (Windows NT LanManager)

Unter OS/2 kommen zusätzliche Varianten ins Spiel, die Microsoft gegenüber dem eigenen PDC nicht benötigt. Unter Unix/Linux sind SMB-Emulatoren bekannt, etwa LanManager for Unix bzw. Samba (eine Verballhornung von SMB). Der Hergang im aktuellen Beispiel ist wie folgt: ■ ■ ■ ■

Der Domain-Client nennt alle SMB-Dialekte, die er unterstützt. Der Domain-Controller nennt seine Fähigkeiten, jedoch nicht im Klartext, sondern dodiert. Der Domain-Controller gibt den Namen der Domain an, für die er steht. Dieser Vorgang ist im Analyzer auf Grund des Klartexts gut nachvollziehbar, wie die Abbildungen zeigen.

Abbildung 13.16: SMB Verify Dialect: Der Client gibt an, welche SMB-Dialekte er spricht. >>> NEW TECH

489

Kapitel 13 • OSI-Schicht 7: Fallstudie Windows 9x-Client

Abbildung 13.17: SMB Verify Dialect: Antwort des Servers

13.3.4 OSI-Schicht 7: SMB Session Setup/Tree Connect Jetzt erst kommt das eigentliche NetLogon: ■ ■

Domain-Client: SMB Session Setup/and More Domain-Server: SMB Session Accept

Der PDC macht hierbei folgende Angaben: ■ ■ ■

OS-Version: Windows NT 4.0 SMB-Version: NT LanManager 4.0 Domain-Name, etwa NT_DOMAIN

Ist die SMB-Sitzung somit initiiert, kommt die Authentisierung und Authorisierung des Anwenders. Das Anmelden an einer Domain (Master Domain, Single Domain, etc.) wird als Tree Connect bezeichnet.

490

>>> NEW TECH

SMB: NETLOGON

Abbildung 13.18: SMB Session Setup: Anfrage des Clients beim Server

Abbildung 13.19: SMB Session Setup: Antwort des Servers an den Client

>>> NEW TECH

491

Kapitel 13 • OSI-Schicht 7: Fallstudie Windows 9x-Client

13.4 SMB: Create (and More) Nunmehr werden mehrere Zugriffsschlüssel eingerichtet, um Server-Ressourcen ansprechen bzw. nutzen zu dürfen. Die Zugriffsschlüssel werden File Handle genannt. In aller Regel wird erst der Zugriff auf das Share eingeleitet; danach folgen die Zugriffe auf die Dateien. Es können aber auch Zugriffe auf logische Prozesse stattfinden, etwa SAMR (Security Account Manager) oder auf den SPOOLSS (Spool Server Service); diese Zugriffe werden so behandelt wie Dateizugriffe, denn auch hier gibt der Server Zugriffsschlüssel zurück. Alle Zugriffe werden mit dem Create-Befehl des Clients eingeleitet; der Server gibt jeweils einen Zugriffsschlüssel zurück und in der Folge gibt der Client nur noch diesen Zugriffsschlüssel an. In diesen Paketen ist kein NetBIOS-Protokoll-Header enthalten, das Aushandeln dieser Sitzungsfunktionen findet ohne das ursprüngliche Session Protocol NetBIOS statt. Die Session-Funktionen des Microsoft Client/Server Netzwerkes liegen heute sämtlich im SMB-Protokoll. Bei Windows 2000 und Windows XP geht das inzwischen so weit, dass sogar SMB nicht über den TCP-Port 139 läuft, sondern über den TCP-Port 445.

13.4.1 Create – LSARPC Zunächst wird ein Benutzername lokal auf dem Arbeitsrechner bestätigt. Dies hat u.a. mit der SID (Security ID) des Anwendernamens in der lokalen Registry zu tun. Mit der Funktion LSARPC wird die lokale SID mit den Angaben des PDC in dessen Datenbank (SAMR, Security Account Manager) abgeglichen (siehe Abbildungen 13.20 bis 13.22).

13.4.2 Create – NETLOGON Ist die SID bestätigt, kann das NetLogon erfolgen (siehe Abbildungen 13.23 und 13.24).

13.5 WINS-Refresh: irreguläre Wiederholungen Im aktuellen Beispiel folgen mehrere WINS-Registration-Requests und WINSRefresh-Requests, die vom Client an den WINS-Server gerichtet werden.

13.5.1 Vermutung: Die WINS Lease Time ist zu kurz Dies ist unüblich bzw. fehlerhaft, denn es lässt vermuten, dass die WINS Lease Time viel zu kurz ist. Welcher Fehler dem nun tatsächlich zugrunde liegt, ist mangels weiterer Messdaten nicht mehr nachvollziehbar.

492

>>> NEW TECH

WINS-Refresh: irreguläre Wiederholungen

Abbildung 13.20: Client-Request auf Einrichtung eines Zugriffsschlüssels auf die Funktion LSA-RPC

Abbildung 13.21: Rückgabe des Zugriffsschlüssels durch den Server: File Handle = 0x0800

>>> NEW TECH

493

Kapitel 13 • OSI-Schicht 7: Fallstudie Windows 9x-Client

Abbildung 13.22: Das Beenden der LSA-RPC-Funktion wird als Close File dargestellt: Auch Funktionsaufrufe werden wie Dateizugriffe kodiert.

Abbildung 13.23: Einrichten des Zugriffsschlüssels für die Funktion NETLOGON

494

>>> NEW TECH

WINS-Refresh: irreguläre Wiederholungen

Abbildung 13.24: Rückgabe des Zugriffsschlüssels für NETLOGON durch den Server: File Handle = 0x0801

13.5.2 Messdaten: Filter auf WINS und DHCP Ein Filter auf die Messdaten gibt eine Übersicht, was die DHCP- und WINSDialoge anbetrifft.

Abbildung 13.25: Fehlerhafte Endlosschleife von WINS-Refreshs: Registrations-Bestätigungen nach Ablauf der WINS Lease Time

>>> NEW TECH

495

Kapitel 13 • OSI-Schicht 7: Fallstudie Windows 9x-Client

13.6 TraceMagic: Auswertungen und Tabellen Die in diesem Beispiel dargestellten Vorgänge in den Name Services sowie die Paarbeziehungen (Conversation Pairs) können über TraceMagic automatisch ausgewertet und tabellarisch dargestellt werden. Dies geschieht über die TraceMagic-Funktion HostMagic: ■ ■

HostMagic/SingleHosts: Name Services, DHCP, Rx/Tx-Statistiken HostMagic/HostPairs: Paarbeziehungen/Conversation Pairs

13.6.1 HostMagic/SingleHosts Die Abbildung 13.26 zeigt die Auswertung der DNS-Dialoge. Die Ergebnisse für WINS und DHCP sind weiter oben in Abbildung 13.3 (DHCP) und Abbildung 13.11 (WINS) zu sehen.

Abbildung 13.26: DNS-Tabelle und Rx/Tx-Tabelle für MAC-Adressen/IP-Adressen (HostMagic/SingleHosts-Tabelle in MS Excel)

13.6.2 HostMagic/HostPairs Es kann von erheblichem Interesse sein, nachzuvollziehen, wer mit wem wie viele LAN-Pakete ausgetauscht hat. Da auch die Möglichkeit besteht, diese Paarbeziehungen nicht nur Host-to-Host, sondern auch Subnet-to-Subnet darzustellen, ergibt sich daraus ein erhebliches Planungsinstrument für Migrationen bzw. fürs

496

>>> NEW TECH

TraceMagic: Auswertungen und Tabellen

Netzwerk-Redesign, wenn es darum geht, die Hauptverkehrsströme zu erkennen. Allerdings sollte dies über Werkzeuge wie Cisco-Works leichter möglich sein oder über Public Domain-Werkzeuge wie NTOP.

Abbildung 13.27: Paarbeziehungen Host-to-Host (HostMagic/SingleHosts-Tabelle in MS Excel)

Abbildung 13.28: Paarbeziehungen Subnet-to-Subnet (HostMagic/HostPairs-Tabelle in MS Excel)

>>> NEW TECH

497

Kapitel 13 • OSI-Schicht 7: Fallstudie Windows 9x-Client

13.6.3 HostMagic/TCP-Port Statistics Um auf TCP-Ebene die Vorgänge leicht zu überblicken, sollten bei der HostMagic-Analyse die TCP-Port Statistics parallel mitlaufen (sofern man sie nicht später in der SpiderMagic-Analyse mitlaufen lässt). Es ist leicht zu erkennen, welcher IP-Host etwa TCP Retransmissions sendete, wer mit TCP-RST Abbrüche signalisierte und so weiter.

Abbildung 13.29: TraceMagic/HostMagic/TCP-Port Statistics (Beispiel 1)

Abbildung 13.30: TraceMagic/HostMagic/TCP-Port Statistics (Beispiel 2)

Abbildung 13.31: TraceMagic/HostMagic/TCP-Port Statistics (Beispiel 3)

498

>>> NEW TECH

TraceMagic: Auswertungen und Tabellen

Abbildung 13.32: TraceMagic/HostMagic/TCP-Port Statistics (Beispiel 4)

Abbildung 13.33: TraceMagic/HostMagic/TCP-Port Statistics (Beispiel 5)

13.6.4 SpiderMagic/TCP/IP-Analyse (Übersicht) Einen Überblick über die Fehler und Symptome in der Datenkommunikation verschafft die SpiderMagic-Analyse. Ausführlichere Beschreibungen hierzu sind in den anderen Schicht-7-Kapiteln enthalten. Die Auswertung über das TraceStatistics-Datenbank-Modul von SpiderMagic ist u.a. wegen des Zugriffs auf die TraceMagic-Knowledgebase schneller und effizienter als die Arbeit mit MS Excel. Jedoch hat die Weiterverarbeitung über MS Excel den großen Vorteil, ■ ■

dass die Tabellen per E-Mail leicht verschickt werden können und dass mit Makros benutzerdefinierte Auswertungen möglich sind.

Von Fall zu Fall kann mal die eine, mal die andere Variante wirksamer sein.

>>> NEW TECH

499

Kapitel 13 • OSI-Schicht 7: Fallstudie Windows 9x-Client

Abbildung 13.34: TraceMagic/SpiderMagic/TCP/IP-Ergebnisstatistik (1)

Abbildung 13.35: TraceMagic/SpiderMagic/TCP/IP-Ergebnisstatistik (2)

500

>>> NEW TECH

TraceMagic: Auswertungen und Tabellen

Abbildung 13.36: TraceMagic/SpiderMagic/TCP/IP-Ergebnisstatistik (3)

>>> NEW TECH

501

Kapitel 14 OSI-Schicht 7: Fallstudie Windows XP-Client Quelle: München, 2002

Die folgende Darstellung beruht auf einer Trace-Datei mit nur 7.349 Frames – und doch ist diese kurze Aufzeichnung reich an Befunden, die beispielhaft sind sowohl für typische Fehler unserer Tage (Stand 2002) wie auch für die Herangehensweise bei der Diagnose. Gegenstand des Interesses ist ein Windows XP-Client mit der Adresse IP = 192.168.2.195, der sich vordergründig dadurch auszeichnet, dass für den Anwender insbesondere bei der Netzwerk-Anmeldung alles sehr, sehr langsam vorangeht. Da im Hause des Kunden Bit-Ratenengpässe eher unwahrscheinlich sind, ist der bekannte Anwendersatz »Das Netzwerk ist langsam.« eher in Zweifel zu ziehen; also muss herausgefunden werden, welche anderen Ursachen für die Verzögerungen in Frage kommen. Heraus kommt ein ganzes Panoptikum mehr oder weniger hübscher Fehler. Alles zusammen ist jedoch hervorragend geeignet, als Beispiel in diesem Buch zu dienen. Wichtig ist der Hinweis, dass der Windows XP-Client auch mit den Novell NetWare-Treibern ausgerüstet ist, was einige seiner Verhaltensweisen in ein besonderes Licht rücken wird. Weiterhin muss darauf hingewiesen werden, dass in diesem Kapitel nicht allein der Appl. Layer eine Rolle spielt, sondern auch Vorgänge auf Layer 3 (Network bzw. IP), Layer 4 (Transport bzw. TCP) und Layer 5/7 (Name Services bzw. WINS, NetBIOS, DNS). So gesehen ist diese Fallstudie wie aus dem Leben gegriffen: Denn häufiger als allgemein angenommen wird, überlagern sich Fehlerbilder der verschiedenen Protokolle und Schichten und Wechselwirkungen sind teilweise von zentraler Bedeutung für das Eintreten von Verzögerungen, Abbrüchen und andere Fehler. Die Aufzeichnung entstand mit einem Ethereal-Analyzer, der den Trace im TcpDump-Format (.DMP) speicherte. Die Auswertung erfolgte mit den TraceMagic-Modulen HostMagic und SpiderMagic. Zunächst wird die Vorgehensweise in TraceMagic dargestellt, da hier die Basis für die spätere Durchsicht der Ergebnisreports gelegt wird. Danach werden die Ergebnisse besprochen und es wird auf typische Fehler der LAN/WAN-Umgebung hinwiesen. Es versteht sich von selbst, dass auch diese Messdaten vor Anfertigung der Abbildungen über das TraceAnon-Modul anonymisiert wurden, indem IPAdressen, DNS- und NetBIOS-Namen ausgetauscht wurden. >>> NEW TECH

503

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

14.1 TraceMagic: Wann welches Modul? Die vier am häufigsten verwendeten Module zur Verarbeitung von Messdaten sind: TraceMagic-Modul

Einsatzgebiet

FilterMagic

Dient dazu, gemäß der im TraceFilter-Modul gesetzten Filterkriterien beliebige Frames aus den Original-TraceDateien herauszukopieren und in eine (mehrere) neue Ergebnis-Trace-Datei(en) hineinzuschreiben. Es können weit über 500 Filterkriterien je Durchgang definiert werden; im Hintergrund arbeitet eine mächtige Datenbank zur dauerhaften Speicherung/Bearbeitung dieser Filter. Keine eigene Intelligenz/kein Experten-System

FindMagic

Dient dazu, alle Frames herauszukopieren (wie bei FilterMagic), die genau einem einzigen Suchkriterium entsprechen. Lohnt nicht, wenn sehr viele Treffer zu erwarten sind. Ist extrem schnell, wenn die Zahl der Treffer eher gering ist und schmerzhaft große Datenbestände durchsucht werden müssen. Keine eigene Intelligenz/kein Experten-System

HostMagic

Eindimensionale Analyse: Alle Befunde werden mit Bezug auf den einzelnen Host gesehen (keine Dialog- bzw. Ablauf-Analyse). Experten-System zur Analyse insbesondere der IP-basierenden Namensdienste (WINS, NetBIOS, DNS) sowie der DHCP-Vorgänge. Darüber hinaus können alle aktiven Komponenten wie Switches/ Bridges, Router, Server etc. erfasst werden. Weiterhin können Verkehrstabellen erzeugt werden: Wer hat wie viele Pakete gesendet/empfangen? Zudem werden Adress- und Namenstabellen erstellt (MAC, IP, NetBIOS, DNS).

SpiderMagic

Entspricht am meisten der Vorstellung eines AnalyzerExperten-Systems. Untersucht Datendialoge der verschiedensten Art. Untermodule: MAC (Ethernet, TokenRing, FDDI), LLC-II/SNA, IP-ICMP-TCP (mit Zusätzen wie Name Services etc.), Appl. Layer (NCP = Novell NetWare; SMB = Windows, OS-2, Samba; HTTP = WWW; Oracle TNS = TCP Port 1521; Voice over IP = RTP Version 2/ Type 18 bzw. G729 Audio, RTCP Version 2, Type 200/ 201); File Reconstruction/Script Follow-Up = rc.files. Unterstützt Ergebnistabellen und Datenbanken für bis zu 65.000 IP-Hosts mit jeweils über 200 Ereignis- und Fehlerzählern zu den TCP/IP-Protokollen.

Tabelle 14.1: Die vier wichtigsten TraceMagic-Module und ihre Unterschiede

504

>>> NEW TECH

TraceMagic/HostMagic

Jede LAN-Analyse wird mit den beiden Modulen HostMagic und SpiderMagic arbeiten. Sofern sich hierbei interessante Hinweise ergeben, die zu weiteren Nachforschungen Anlass geben, können gezielt mit FilterMagic bzw. FindMagic nachträglich bestimmte LAN-Pakete aus den aufgezeichneten Originaldaten herausgezogen werden. Die Ergebnisreports liegen dann in folgenden Formaten vor: .DB (Datenbanken), .TXT (lesbare Text-Dateien), .CSV (Listen können in Excel etc. weiterverarbeitet werden), .HTML (automatisch erzeugte HTML-Projekte), sowie neu erzeugte Trace-Dateien mit allen Frames, die sich als interessant im Sinne der Analyse erwiesen haben.

14.2 TraceMagic/HostMagic Als Erstes – wie grundsätzlich zu empfehlen ist – wird eine Auswertung mit dem Modul HostMagic durchgeführt, ■

um über die Funktion Device Detection die aktiven Komponenten zu erfassen (Switches, Router, Server etc.),

■

um über die Funktion SingleHosts die Name Services in den Blick zu nehmen sowie um Tabellen mit allen MAC-Adressen, IP-Adressen, NetBIOSund DNS-Namen zu erhalten.

Solche dokumentarische Vorarbeit ist immer dann wichtig, wenn es sich um Messdaten eines Kunden handelt bzw. wenn sie aus einem Netzwerk stammen, das man selber nicht hinreichend kennt, denn jede nachfolgende Analyse bzw. Bewertung der Ergebnisdaten, die mit SpiderMagic erarbeitet wird, hängt von Detailkenntnissen dieser Art ab.

14.2.1 Einstellungen vor dem Start Vor dem Start von HostMagic sind einige Einstellungen vorzunehmen und Abfragen zu beantworten. Einstellungen der HostMagic-Funktionen Nachdem im TraceMenu-Fenster die zu verarbeitenden Trace-Datei(en) ausgewählt wurden (hier ist es lediglich eine einzige Trace-Datei), wird das Fenster von HostMagic aufgerufen und die Funktion SingleHosts angewählt. Hier sollte die Check-Box für die Funktion Device Detection mit dem Häkchen versehen werden. Siehe hierzu Abbildung 14.1.

>>> NEW TECH

505

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.1: TraceMagic/HostMagic/SingleHosts (Einstellungen)

Danach wird die START-Schaltfläche per Mausklick aktiviert. Sodann erfolgen einige Abfragen, die für die nachfolgende Verarbeitung unerlässlich sind. Einstellungen der Tabellengröße für "Device Detection" Sofern mit der Funktion "Device Detection" gearbeitet wird, erscheint als nächstes eine Abfrage, für wie viele aktive LAN/WAN-Komponenten die Tabellengröße eingerichtet werden soll (siehe Abbildung 14.2). Angesichts des massiven Speicherbedarfs von TraceMagic (zumindest dann, wenn im hohen Gigabyte-Bereich Messdaten verarbeitet werden) ist eine dynamische Anpassung der Tabellengröße zur Laufzeit zu instabil; daher wird der Speicherplatz für diese Tabelle (und für alle anderen Tabellen ebenfalls) vor dem eigentlichen Analysebeginn im Hauptspeicher reserviert. Eingabe des Vorgangstitels für den aktuellen Analyse-Durchgang Sodann erfolgt die Eingabe eines Vorgangstitels, unter dem in der TraceHistoryDatenbank der aktuelle Analyse-Durchgang abgelegt wird. Diese Eingabe dient dazu, den aktuellen Vorgang später leichter wiederfinden bzw. zuordnen zu können. Es ist keine technisch notwendige Eingabe. (Siehe Abbildung 14.3)

506

>>> NEW TECH

TraceMagic/HostMagic

Abbildung 14.2: TraceMagic/HostMagic/Device Detection: Abfrage der Tabellengröße

Abbildung 14.3: Eingabe eines Vorgangstitels für die TraceHistory-Datenbank

>>> NEW TECH

507

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Einstellungen der Tabellengröße (Adressen, Namensdienste) Sodann erscheint eine zweite Abfrage bezüglich einer Tabellengröße, dieses Mal zu der SingleHosts-Tabelle mit MAC/IP-Adressen, WINS/NetBIOS/DNS-Namen und Rx/Tx-Statistiken. (Siehe Abbildung 14.4) Aus der Sicht von TraceMagic spricht nichts dagegen, ständig den größten Wert von 65.000 auszuwählen; auf Rechnern mit wenig Hauptspeicher sollte bei ersichtlich wenig IP-Adressen aber Rücksicht genommen und der Speicherhunger begrenzt werden.

Abbildung 14.4: Angabe, wie viele IP-Adressen (und MAC-Adressen) maximal zu erwarten sind, entsprechend wird die Tabellengröße ausgelegt.

Einstellungen zu Ergebnis-Trace-Datei und Event-Log Danach kommt die Abfrage, ob alle LAN-Pakete, die im Sinne der Analyse von Interesse waren, herausgefiltert und in eine neu zu erzeugende Trace-Datei (namens TM.HIT.FRAMES.*, immer im Format des Original-Analyzers) hineingeschrieben werden sollen. Hier sollte aus verschiedenen Gründen immer mit JA geantwortet werden: Erstens ist dies die Bedingung dafür, dass die Event-LogDatei TM.HIT.FRAMES.*.LOG.TXT geführt wird, und zweitens macht die gefilterte Ergebnis-Trace-Datei die Befunde leichter verifizierbar. (Siehe Abbildung 14.5) Anders verhält es sich mit der Frage, ob neben dem Standard-Event-Log noch zusätzliche Separat-Event-Logs je Protokoll geführt werden sollen. Dies sollte bei großen Datenmengen mit NEIN beantwortet werden, um die Geschwindigkeit nicht zu stark abzubremsen. Da diese gefilterten Zusatz-Logs jederzeit über das EventFilter-Modul nachgeholt werden können, kann hier ohne Bauchschmerzen auf sie verzichtet werden. Allerdings ist es bequem, sie einfach mitlaufen zu lassen. Dies muss jeder Anwender für sich selbst entscheiden.

508

>>> NEW TECH

TraceMagic/HostMagic

Abbildung 14.5: Abfrage, ob die analyserelevanten LAN-Pakete herausgefiltert und neu abgespeichert werden sollen (hier sollte IMMER mit JA geantwortet werden), und ob separate SpezialLogs geführt werden sollen (kann mit NEIN beantwortet werden, da dies später nachgeholt werden kann)

Letzte Abfrage vor Beginn der Analyse Sodann erscheint die letzte Abfrage vor dem Analyse-Start, die nur dazu dient, noch einen Abbruch durchführen zu können. Zwar kann auch jederzeit später während der laufenden Analyse abgebrochen werden. Da dann aber immer das Schreiben der Ergebnisreports anfällt, können spätere Abbrüche zu Verzögerungen führen. (Siehe Abbildung 14.6)

Abbildung 14.6: Letzte Frage vor dem START: Soll die Analyse durchgeführt werden (mit den vorgenommenen Einstellungen) oder soll doch noch abgebrochen werden?

>>> NEW TECH

509

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Mit dem Beginn der Trace-Untersuchung erscheint ein Mitteilungsfenster, welches das Unterverzeichnis ausweist, in welchem sämtliche Ergebnis-Dateien abgelegt werden, wobei hier zwei besondere Report-Dateien eigens genannt werden, nämlich die gefilterte Ergebnis-Trace-Datei samt der zugehörigen Event-Log-Datei.

Abbildung 14.7: Mitteilung, in welchem Verzeichnis und unter welchem Namen die gefilterte ErgebnisTrace-Datei samt der Event-Log-Datei abgelegt wird

Während die Analyse läuft, erscheint die Standardanzeige mit mehreren blauen Balken, die den Verarbeitungsfortschritt anzeigen (siehe Abbildung 14.8).

Abbildung 14.8: Standarddarstellung während der laufenden Analyse. Die blauen Balken zeigen den Verarbeitungsfortschritt an. Die STOP-Schaltfläche dient für den Fall, dass ein Abbruch vorgenommen werden soll.

510

>>> NEW TECH

TraceMagic/HostMagic

Die unter [HOST:MAGIC] sichtbaren Statistiken sind nicht wirklich als lesbarer Analyse-Hinweis gedacht, sondern geben nur einen kurzen Blick auf das Ausmaß der Tabelleneinträge. Um noch während der laufenden Trace-Verarbeitung Einblick in die Ergebnisse zu bekommen, sollte die Seite [TRACE:EVENTS] angewählt werden. Entsprechende Darstellungen hierzu sind weiter unten im Abschnitt zum SpiderMagicModul zu sehen. Ist die Analyse beendet, werden die Ergebnisse in die Datenbanken sowie in Text- und CSV-Dateien geschrieben (siehe SpiderMagic). Ganz zum Schluss werden die Original-Traces sowie die neu erzeugten ReportDateien überprüft und in die TraceHistory-Datenbank aufgenommen (siehe Abbildung 14.9).

Abbildung 14.9: Mitteilung mit der Bitte um Geduld, während Ausgangs- und Ergebnis-Dateien in die TraceHistory-Datenbank aufgenommen werden

Jede Analyse in TraceMagic endet mit dem Menüfenster der TraceHistoryDatenbank, wobei das Blatt [DETAILS: TRACE + REPORT] automatisch angewählt ist (siehe Abbildung 14.10).

Abbildung 14.10: Ende einer jeden TraceMagic-Analyse: das TraceHistory-Fenster. Tabelle links: Die Original-Trace-Dateien, die untersucht wurden. Tabelle rechts: Die Ergebnis-Dateien (Reports) mit Ausnahme der Datenbanken, die über die Schaltfläche mit dem TabellenSymbol erreichbar sind

>>> NEW TECH

511

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Das Blatt [TRACE:EVENTS/TRACE:FILTER] ist für die Nachbearbeitung der Event-Log-Datei(en) praktisch immer unerlässlich und wird auch im vorliegenden Fall (siehe unten) von Bedeutung sein.

14.2.2 Ergebnisse: Device Detection (aktive Komponenten) Die Funktion Device Detection liefert eine Tabelle in der folgenden, immer gleich lautenden Datei: TM.DD.DeviceDetection.TABLES.~~01~~.TXT

Sie ist in verschiedene Abschnitte unterteilt, in denen nach verschiedenen Merkmalen sortiert die Ergebnisse ausgegeben werden. Diese Sortierungsmerkmale sind: IP-Adresse, TCP-Port und Funktion.

Abbildung 14.11: Ergebnis-Datei der Device Detection-Funktion (1): Ausschnitt mit IP-Adresse, Name und Funktionsbeschreibung aktiver Komponenten

512

>>> NEW TECH

TraceMagic/HostMagic

Abbildung 14.12: Ergebnis-Datei der Device Detection-Funktion (2): Ausschnitt mit TCP-Ports bzw. Services, die von jedem IP-Server unterstützt werden

Der eigentliche technische Zweck der Funktion Device Detection ist es, aus den Messdaten alles herauszufischen, was kein Client ist. Die sodann als Server bzw. aktive Netzwerk-Komponente übrig bleibenden Kommunikationsteilnehmer werden in Funktionsklassen aufgeteilt, die hier als ToS/Type of Networking Service bezeichnet werden und rein willkürlich gewählt sind; diese Typen-Klassifizierung hat nichts mit etwaigen anderen, allgemein verwendeten Einteilungen zu tun. (Siehe Abbildung 14.13) Für den Fortgang der Dinge ist wichtig, die für die Windows-Welt zuständigen Primary Domain Controller (PDC) bzw. Backup Domain Controller (BDC) erkannt zu haben (in der Tabelle teilweise im Namen als SDC bezeichnet für Secondary Domain Controller) sowie die Novell NetWare-Server (ausweislich des TCP-Ports 524 für NCP-over-TCP/IP). Auch die DNS-Server sind hier erkennbar, sie werden noch eine wichtige Rolle bei der Betrachtung recht auffälliger Verhaltensweisen des Windows XP-Clients spielen.

>>> NEW TECH

513

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.13: Ergebnis-Datei der Device Detection-Funktion (3): Ausschnitt der Auflistung aller aktiven Komponenten nach Service-Typ

14.2.3 Ergebnisse: Name Services (WINS, UDP-138, DNS) Ein erster Schritt, sich einem LAN-Trace zu nähern, ist praktisch immer die Betrachtung der Namensdienste, da praktisch überall, wo Windows-Rechner arbeiten, irgend etwas in diesem Bereich nicht so ist, wie es sein sollte. Das ist übrigens keine üble Nachrede, sondern einfach praktische Erfahrung, die sich immer wieder bestätigt. So ist es auch hier: Kaum blickt man in die Report-Datei, wird es auch schon interessant: TM.HM.HostMagic.TABLES.~~SINGLE.HOSTS~~.TXT TM.HM.HostMagic.TABLES.~~SINGLE.HOSTS~~.CSV

Hier in den Abbildungen ist nur die Text-Datei zu sehen; die für eine Weiterverarbeitung in Excel gedachte CSV-Datei wird hier übergangen, da sie exakt dieselben Daten enthält. Weiterhin nicht zu sehen sind Auswertungen von DHCPVorgängen sowie Rx/Tx-Statistiken, da sie hier im aktuellen Fall entweder nicht gegeben oder aber nicht von Belang sind.

514

>>> NEW TECH

TraceMagic/HostMagic

Abbildung 14.14: TraceMagic/HostMagic/SingleHosts (1): Ergebnis-Datei (Ausschnitt) mit Auswertung der WINS- und NetBIOS-Pakete

Die WINS- und DNS-Statistiken weisen folgende Kopfzeile oberhalb der Zahlenspalten rechts auf: (ClReq:[Ucast/Bcast](SvRep:[SvHit:SvErr])

Daraus ergeben sich sechs Spalten mit folgenden Bedeutungen: Spalten-Titel

Bedeutung

ClReq

Client Requests (alle zusammen, Broadcasts und Unicasts)

Ucast

Client Requests/nur die Unicasts

Bcast

Client Requests/nur die Broadcasts

SvRep

Server Replies (alle zusammen, Treffer und Fehler)

SvHit

Server Hits/Name Server konnte die Auflösung bieten

SvErr

Server Error/Name Server konnte nicht helfen

Tabelle 14.2: HostMagic/SingleHosts: Bedeutung der Titel im Spaltenkopf bei WINS und DNS

Die Statistiken zu UDP-Port 138 bzw. zu NetBIOS-over-IP/UDP weisen folgende Kopfzeile oberhalb der Zahlenspalten rechts auf: (RxReq:[Ucast/Bcast](TxRep:[Ucast/Bcast])

>>> NEW TECH

515

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.15: TraceMagic/HostMagic/SingleHosts (2): Ergebnis-Datei (Ausschnitt) mit Auswertung der NetBIOS- und DNS-Pakete

Daraus ergeben sich sechs Spalten mit folgenden Bedeutungen: Spalten-Titel

Bedeutung

RxReq

Received Requests: Anzahl aller NetBIOS-Pakete, die an den vorbezeichneten NetBIOS-Teilnehmer gesendet wurden, und zwar Unicasts wie Broadcasts (ungeachtet dessen, ob es diesen NetBIOSTeilnehmer überhaupt gibt)

Ucast

Received Requests/nur die Unicasts

Bcast

Received Requests/nur die Broadcasts

TxRep

Transmitted Replies Anzahl aller NetBIOS-Pakete, die vom vorbezeichneten NetBIOS-Teilnehmer gesendet wurden, und zwar Unicasts wie Broadcasts, wobei möglich ist, dass auch unaufgefordert Pakete gesendet wurden (denen also keine »Received Requests« gegenüber stehen).

Ucast

Transmitted Replies/nur die Unicasts

Bcast

Transmitted Replies/nur die Broadcasts

Tabelle 14.3: HostMagic/SingleHosts: Bedeutung der Titel im Spaltenkopf bei UDP-Port 138 = NetBIOSover-IP/UDP

516

>>> NEW TECH

TraceMagic/HostMagic

Auffälligkeiten bei WINS Es gab zwei per Unicast gesendete Anfragen zur Auflösung des NetBIOSNamens SCHNEIDT in die zugehörige IP-Adresse; der WINS-Server jedoch konnte nicht helfen – die Statistik weist nur einen Eintrag unter Server Error auf. Wenn es sich bei SCHNEIDT um einen Anwender handelt, der sich eigentlich per WINS-Registration am WINS-Server anmelden müsste, fällt die »Will nicht, kann nicht, weiß nicht«-Antwort des WINS-Servers auf. Als Nächstes fällt auf, dass einige IP-Adressen mit mehreren Namen verbunden sind. Das ist nicht weiter verwunderlich (und ist völlig korrekt), sofern sich die Namen durch ihren NetBIOS-Ressourcen-Typ unterscheiden, der als Hex-Code in den eckigen Klammern steht und der Microsoft-Vorgabe folgt: User, Computer, Share, Workgroup, Domain und so weiter. Am Fuße einer jeden HostMagic-Name Service-Tabelle stehen diese NetBIOS-Ressource-Typen aufgelistet, um sie nachschlagen zu können. Zuletzt stellt sich noch die Frage: Wieso sind bzgl. SCHNEIDT wohl zwei WINS-Requests in der Statistik, aber nur ein WINS-Reply? Nun, das ergibt sich oft aus der Lage des Messpunkts und der Verkehrsführung im LAN: Insbesondere bei redundant aufgebauten Campus-Backbones ergibt sich schnell ein Kreisverkehr (von A nach B links herum, zurück von B nach A rechts herum), der dazu führt, dass nicht alle Pakete am Messpunkt vorbeikommen. Es kann also sein, dass die beiden WINS-Request-Unicasts mal verteilt gerichtet waren an den primären WINS-Server, mal an den sekundären WINS-Server, und nur die Antwort eines der beiden WINS-Server kam ebenfalls wiederum am Messpunkt vorbei. Das ist nichts Ungewöhnliches und führt zu der Schlussfolgerung, dass man gut daran tut, während jeglicher Messung einen separaten Messrechner vor die Namens-Server (WINS, DNS) zu setzen, um wirklich alle Dialoge dieser Art zuverlässig mitzubekommen. Allgemeine Bemerkung zu messtechnischen Erfordernissen Da auch andere Server ähnlich wichtig sind (BOOTP-DHCP, SLP, Time Server bzw. NTP, PDC, BDC, NDS, NIS etc.), ergibt sich daraus für den Verfasser dieses Buches hinsichtlich der Wahl der Messpunkte die Praxis, dass er oft mit vier bis sechs Messrechnern beim Kunden vorfährt, um bei diesen für die Logik des Netzes wichtigen Servern permanent kleinere Messrechner mitlaufen zu lassen (kleiner deswegen, weil dort die Datenmengen erfahrungsgemäß sehr niedrig sind), während mit den großen Messrechnern die Gigabit-Leitungen abgegriffen werden. Spätestens bei dieser Arbeitsweise wird klar, wie wichtig eine Software wie TraceMagic ist, wenn man noch am Abend des ersten Tages ein praktisch vollständiges Bild aller Vorgänge erhalten will, die tagsüber in den Messdatenaufzeichnungen abgebildet wurden. Es zeigt sich darin auch, warum der Verfasser die LAN-Analyzer der etablierten Hersteller sämtlich nicht mehr ernst nehmen kann: Mit Kinderspielzeug kann

>>> NEW TECH

517

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

man einfach keine Komplett-Analyse erreichen und das schon gar nicht unter Zeitdruck, auch nicht bei den unter Gigabit horrenden Datenmengen und schon gar nicht in einer verteilten Umgebung, die auch räumlich eine Herausforderung darstellt (zum Beispiel wenn über den Tag hinweg an verschiedenen Standorten gemessen wird und schon deswegen erst abends wieder ein Blick auf die Messrechner bzw. ihre Daten geworfen werden kann). Der Verfasser ist in der Lage, am Abend des ersten Tages vor Ort ein weitgehend vollständiges Bild der Fehler zu geben, gleich wie komplex sie auch sein mögen: und am Abend kann mit dem Kunden gemeinsam entschieden werden, ob das reicht oder ob der nächste Tag noch drangehängt wird. Hier wird nicht gewartet, bis nach 14 Tagen der erste Bericht kommt: Es wird sofort noch vor Ort ausgewertet (wenigstens in repräsentativen Stichproben), bewertet und entschieden. Das kommt dem Kunden in zweierlei Kriterien zupass: ■ ■

Fehler und Ausfallkosten verlangen nach schnellen Ergebnissen und schnellen Entscheidungen. Klare Aussagen schon am Abend des ersten Tages, der Menge der Messdaten (fast) ungeachtet, erlauben in den folgenden Entscheidungen auch eine Berücksichtigung der Kosten (Honorar des Dienstleisters u.a.m.).

Vom Ergebnis her betrachtet: Wenn man erst einmal mit einem solchen Instrumentarium bzw. mit einem solchen massiven Maschineneinsatz zu arbeiten gewöhnt ist, ergibt sich von selbst, dass WINS/DNS/DHCP-Server etc. völlig selbstverständlich permanent »mitgenommen« werden – gleich, welchen eigentlichen Anlass zur Messung es gab und an welchen Orten man sonst eigentlich Messdaten aufzunehmen vorhat. Es kann und darf nicht sein, dass die Deutung komplexer Abläufe daran scheitert, dass zum Beispiel ein paar Namensauflösungen nicht nachvollzogen werden konnten. Auffälligkeiten bei NetBIOS bzw. UDP-138 Hier fällt negativ auf, dass nach der NetBIOS-Ressource CB_EDV in ihrer Eigenschaft als Domain bzw. als Primary Domain Controller (PDC), gekennzeichnet durch den NetBIOS-Resource-Typ 0x1C, mehrfach per Broadcast gesucht wurde und nicht nur per Unicast. Zwar mögen sechs Broadcasts auf 41 Unicasts gering erscheinen, gleichwohl sollte man sich bei solchen Beobachtungen eine Notiz aufschreiben, um dem später im Detail nachzugehen. In der SpiderMagic-Auswertung (siehe unten) werden wir sehen, warum dieser Hinweis – mal wieder – richtig war. (Der Hinweis könnte auch hier schon in der HostMagic-Analyse aufgelöst werden, um jedoch doppelte Arbeit zu vermeiden, ist das alles in den SpiderMagic-Abschnitt verlegt worden.)

518

>>> NEW TECH

TraceMagic/HostMagic

Ansonsten erscheint diese NetBIOS- bzw. UDP-138-Statistik wenig auffällig (was selten der Fall ist und hier sehr wahrscheinlich nur dem Umstand zu verdanken ist, dass lediglich der Datenverkehr eines einzigen Clients aufgenommen wurde). Auffälligkeiten bei DNS Hier lacht das Herz des Chronisten, weil mal wieder die ersten für eine Windows-Umgebung typischen Auffälligkeiten bzw. Fehler aufleuchten. Es ist unschwer zu erkennen, dass der DNS-Domain-Name im aktuellen Subnetz vinet.de lautet. Wenn das nun so ist, sollte sinnigerweise gleich nach jeglichem DNS-Host in der Form gesucht werden, dass der Full Qualified [DNS] Name (FQN) verwendet wird – und nicht nur der Host-Name ohne Domain-Suffix (siehe Tabelle 13.4). DNS-Name

Bedeutung

vi-ed-ni01

Nur Host-Name. Der Domain-Suffix fehlt (und daher kein FQN).

vi-ed-ni01.vinet.de

Voll ausgeprägter DNS-Name mit Host-Name (vi-ed-ni01) sowie Domain-Suffix (vinet.de) und somit ein Full Qualified DNS Name (FQN)

Tabelle 14.4: DNS: Unterschied zwischen Host-Name, Domain-Suffix und FQN

Es ist schnell zu erkennen, dass die DNS-Requests, die lediglich einen HostNamen übergeben haben, nicht zum Erfolg führten: Die Spalte Server Hit weist jeweils die Trefferzahl 0 (Null) auf und entsprechend wird die IP-Adresse hilfsweise mit 0.0.0.0 angegeben. Dagegen konnten die mit einem FQN ausgestatteten DNS-Requests jeweils erfolgreich beantwortet werden. Wie erklärt sich nun dieses Verhalten von DNS-Clients, erst einmal so, dann einmal so anzufragen? Dies erklärt sich aus der Aufwärts-Kompatibilität der Namensdienste aus der Sicht von Microsoft für die Phase der Migration von NetBIOS/WINS zu DNS: Angenommen, ein Rechner hatte zu NetBIOS-Zeiten den Namen ASTERIX: Dann konnte dieser Rechner zum Beispiel über START/ SUCHEN/COMPUTER/ASTERIX gefunden werden, da die dadurch ausgelöste Suche per WINS (UDP-137) oder per NetBIOS-Broadcasts (UDP-138) in der Regel zum Erfolg führte. Was passiert nun, wenn der Rechner ASTERIX das NetBIOS-Namens-System verließ und in DNS aufgenommen wurde und nunmehr asterix.localdomain.de heißt? Was geschieht weiter, wenn der Anwender weiterhin über START/ SUCHEN/COMPUTER nach ASTERIX sucht? Dann hat Microsoft folgende Möglichkeiten: 1. die Suche scheitern lassen, 2. die Suche im Hintergrund auf eigene Faust auf DNS ausdehnen. >>> NEW TECH

519

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Hierbei handelt es sich um die NetBIOS-Suche über DNS, die auch in der System-Steuerung von Windows (de-)aktiviert werden kann. Dieser Gedanke war im Grunde naheliegend, verkehrt sich aber in vielen Fällen in sein Gegenteil, weil bzw. wenn – wie hier – ersichtlichist, erfolglos immer zuerst nach dem alten NetBIOS-Namen gesucht wird (ohne Domain-Suffix) und wenn dadurch zu viel Zeit verloren geht, denn jedes Mal muss erst ein Timeout eintreten, bis dann das lokale Domain-Suffix angehängt und die Suche wiederholt wird. Zurück zum Beispiel: Hier ist also schon an den Einträgen der DNS-Ergebnistabelle abzulesen, dass Anwender wieder einmal sagen werden: »Das Netzwerk ist langsam.« Denn zu viele Zeitüberschreitungen summieren sich da auf, wenn jeweils sinnlos auf die Antwort bei DNS-Requests nach VI-ED-NI01 und VI-ED-NI02 und PDC gewartet wird. Weiter unten in der SpiderMagic-Analyse wird zu sehen sein, wie sinnlos diese DNS-Anfragen wirklich organisiert sind.

14.3 TraceMagic/SpiderMagic Als Zweites wird eine Auswertung mit dem Modul SpiderMagic durchgeführt, womit eine umfangreiche Client/Server-Dialog-Analyse vorgenommen wird.

14.3.1 Einstellungen vor dem Start Nach Aufruf des SpiderMagic-Fensters sind die verschiedenen Einstellungen vorzunehmen. Hierbei stellt sich grundsätzlich die Frage: ■ ■ ■ ■ ■

Sollen nur die Layer 1-2 untersucht werden (Physical/MAC)? Sollen nur die Layer 3-4-5 untersucht werden (TCP/IP mit Name Services)? Soll nur der Layer 7 untersucht werden (Application)? Sollen die Layer 3-4-5-7 gemeinsam untersucht werden? Sollen die Layer 1-2-3-4-5-7 gemeinsam untersucht werden?

Je nach vermutetem Fehler und je nach verfügbarer Zeit wird die Entscheidung zu treffen sein. Erfahrungsgemäß kann die Dauer einer TCP/IP-Analyse niemals vorhergesagt werden. Ein starkes Aufkommen an TCP Retransmissions beispielsweise kann die Dauer der Verarbeitung stark ansteigen lassen. Dagegen ist die Layer-7Analyse überwiegend schnell und zügig – sofern nicht zu viele File-Server auf Client-Requests mit Error-Codes antworten. Es ist also nicht wirklich vorhersehbar, wie viel Zeit die Durchgänge in Anspruch nehmen werden. Die gemeinsame Untersuchung der verschiedenen Layer lässt sich nur über das TCP/IPAnalyse-Modul erreichen.

520

>>> NEW TECH

TraceMagic/SpiderMagic

Im vorliegenden Fall sollen die Layer 3-4-5-7 gemeinsam untersucht werden, während physikalische Fehler mal unberücksichtigt bleiben. Im aktuellen Beispiel werden die Einstellungen wie folgt vorgenommen: Einstellungen für die Applikationsprotokolle/Layer 7 Zunächst werden in der Abteilung [APPLICATION] die Analyse-Funktionen zu SMB (Server Message Block = Windows, OS/2, Samba), NCP (NetWare Core Protocol = Novell NetWare) und HTTP (HyperText Transport Protocol = WWW) aktiviert sowie die Doppelfunktion File Reconstruction (rc.files) bzw. Script Command Tracking/Script Follow-Up (siehe Abbildung 14.16).

Abbildung 14.16: Einstellungen zu der Doppelfunktion File Reconstruction (rc.files) und Script Follow-Up. Diese Funktion ist unverzichtbar für die Client/Server-Analyse in der Phase des Bootens und der Netzwerk-Anmeldung.

Bei File Reconstruction handelt es sich um eine Funktion, die den Inhalt beliebiger Dateien, die durch Clients von Servern gelesen werden, in einem Unterverzeichnis des TraceMagic-Projekts rekonstruiert werden (das Verzeichnis heißt rc.files für reconstructed files). Bei Script Command Tracking/Script Follow-Up handelt es sich um eine Funktion, die das Client-Verhalten mit Script-Befehlen abgleicht, die der Client über Script-Dateien (.BAT, .CMD etc.) erhalten hat, indem er sie vom Server zuvor geladen hat.

>>> NEW TECH

521

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Diese Funktionen sind für eine umfassende Client/Server-Analyse unverzichtbar, da nur so fehlerhafte Befehlsausübung zurück geführt werden kann auf die jeweilige Script-Datei bzw. auf die einzelnen Script-Befehle, die das Verhalten des Clients steuern. Beim Abarbeiten von Dateien der Typen .BAT und .CMD macht TraceMagic anstandslos sichtbar, welche Script-Datei die Befehle steuert und welche ScriptZeile aktuell ausgeführt wird. Der Nutzen dieser Funktion ist evident. Der Netzwerk-Analyst braucht nicht mehr betteln zu gehen, um von Server-Administratoren die Scripts übergeben zu bekommen. Auch bedarf es nicht mehr der langwierigen manuellen Durchsicht – das berühmte Stochern im Nebel entfällt. Diese Funktion hat sich in der Praxis phänomenal bewährt und manche Diagnose überhaupt erst ermöglicht, die sich sonst kaum hätte stellen lassen. Und wieder einmal kann der Verfasser dieser Zeilen nicht anders, als die Hersteller angeblicher Marktführer-Produkte zu fragen, auf welchem Mond bzw. auf welcher Umlaufbahn sie eigentlich die letzten zehn Jahre verbracht haben. Alle Analyzer, die 10.000 Euro und mehr kosten, können leider praktisch nichts davon. Vielleicht ist das ein Naturgesetz: je teurer, desto weniger anwendbar! Man kann wirklich nur noch den Kopf schütteln. Nun, wir werden im aktuellen Fall ein bisschen sehen, was diese Funktion zu leisten im Stande ist. Einstellungen für die TCP-IP-Protokolle/Layer 3-4-5 Sodann wird in die Abteilung [ARP – IP – ICMP – TCP] gewechselt, die dortigen Einstellungen für die Protokolle ARP, IP, ICMP und TCP können in aller Regel so übernommen werden, wie sie sind. Unter [HOST CONFIGURATION/ NAME SERVICES] können zusätzliche Protokolle (de-) aktiviert werden; eine in Ergebnistabellen mündende Analyse der Namensdienste jedoch ist nur über HostMagic möglich. Über [LAYER 7 – APPLICATION] sind die Einstellungen zu den Protokollen SMB, NCP, HTTP etc. erreichbar (schon geschehen, siehe oben). In der Abteilung [.CSV/IP ANON.] ist das Erscheinungsbild der CSVErgebnis-Dateien einstellbar einschließlich der Möglichkeit, die IP-Adressen durch Verfremdung zu anonymisieren (siehe Abbildung 14.17). Hier wird – im aktuellen Beispiel – jedoch nichts weiter verändert und es wird der START-Button per Mausklick aktiviert. Es folgen einige Abfragen, die bereits oben im HostMagic-Abschnitt vorgestellt wurden, etwa die Aufforderung zur Eingabe eines Verarbeitungstitels für die TraceHistory-Datenbank. Im weiteren Fortgang kommt es zur Einrichtung der TCP/IP-Ergebnisdatenbanken; dies wird mit einer kurzen Meldung angezeigt (siehe Abbildung 14.18).

522

>>> NEW TECH

TraceMagic/SpiderMagic

Abbildung 14.17: Einstellungen zur TCP-Analyse. Hier sollte grundsätzlich die Zusatzfunktion TCP/UDP Port Statistics eingeschaltet sein – auch, wenn sie in geringem Umfang zusätzliche Verarbeitungszeit kostet.

Abbildung 14.18: Mitteilung, dass die TraceMagic-Ergebnisdatenbanken vorbereitet werden

Einstellung der Trace-Filter (sofern gewünscht) Sodann kommt die Abfrage, ob Trace-Filter gesetzt werden sollen – was regelmäßig mit NEIN beantwortet wird (siehe Abbildung 14.19). Ein Filter hätte die Wirkung, dass nur genau die LAN-Pakete zur Verarbeitung zum SpiderMagicModul vorgelassen werden, die den gesetzten Filterkriterien entsprechen. Mit dieser Verfahrensweise ähnelt der Trace-Filter den Online-Filtern, die so gerne bei LAN-Analyzern während der Messung gesetzt werden – nur ist es so, dass ein Online-Filter die ausgelassenen Frames endgültig verliert, während sie beim Trace-Filter von TraceMagic ja weiterhin in den aufgezeichneten TraceDateien erhalten bleiben. Daher zeigt sich, dass es immer besser ist, bei der Online-Messung ohne jeglichen Filter zu arbeiten! Wenn Filter gewünscht sind, setzt man sie später in der Offline-Analyse mit TraceMagic.

>>> NEW TECH

523

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.19: Abfrage: Sollen Trace-Filter gesetzt werden? In der Regel wird mit NEIN geantwortet.

Einstellung der Tabellengröße für IP-Host-Statistiken Wie auch bei HostMagic wird abgefragt, wie viele IP-Adressen erwartet werden. Im entsprechenden Umfang wird Hauptspeicher für die TCP/IP Statistiktabellen reserviert, da ein dynamisches Wachsen der Tabellen zur Laufzeit der TraceMagic-Analyse für das Windows-Betriebssystem und seine Speicherverwaltung nicht zuverlässig genug durchgeführt werden kann (siehe Abbildung 14.20).

Abbildung 14.20: Abfrage, für wie viele IP-Adressen die Statistiktabellen ausgerichtet werden sollen zwecks Reservierung des dafür nötigen Hauptspeichers

Es spricht bei hinreichend mit Speicher ausgerüsteten Rechnern nichts dagegen, ständig den größten Wert von 65.500 zu wählen. Ist jedoch der vorliegende Rechner knapp an Hauptspeicher, hilft man, indem man eben nicht unnütz viel Hauptspeicher reserviert (was der Sinn dieser Abfrage ist).

524

>>> NEW TECH

TraceMagic/SpiderMagic

Einstellung der Tabellengröße für die TCP ReTx Packet History Sodann folgt eine Abfrage, wie viele TCP-Pakete während der TraceMagicAnalyse in der TCP Retransmission Packet History nachgehalten werden sollen (siehe Abbildung 14.21).

Abbildung 14.21: Abfrage, wie viele TCP-Pakete während der Analyse in der TCP Retransmission Packet History nachgehalten werden sollen

Dahinter verbirgt sich der folgende Mechanismus: Um die Grenzen zwischen den verschiedenen Trace-Dateien aufzuheben bzw. um TCP Retransmissions auch dann zuverlässig zu erkennen, wenn beispielsweise die Erstübertragung einer TCP-Sequence in der Trace-Datei capture-385.enc liegt und die Wiederholungsübertragung in der Trace-Datei capture-386.enc, werden alle TCP-Header in einen Packet-Buffer im Hauptspeicher gelegt. Die Folge ist, dass beim Wechsel von einer Trace-Datei zur nächsten (im Beispiel: von capture-385.enc zu capture-386.enc) noch 1.000 bzw. 10.000 TCP-Header der vorigen Trace-Datei im Hauptspeicher in der dortigen TCP-ReTx-History liegen und somit für Vergleiche zur Verfügung stehen. Die TCP-ReTx-History ist nicht der einzige Mechanismus, um die zuverlässige Erkennung von TCP Retransmissions zu ermöglichen, und auch nicht der einzige Mechanismus, um die Grenze zwischen jeweils zwei Capture-Files (TraceFiles) aufzuheben, aber es ist ein wichtiger und sehr zuverlässiger Mechanismus. Einer der weiteren Mechanismen arbeitet auf einer Pro-Host-Basis, das heißt, dass für jeden IP-Host, der in den Messdaten auftritt, eine eigene kleine MiniHistory geführt wird. Diese Mini-History führt jedoch nicht bei allen Typen von Retransmissions zur zuverlässigen Erkennung. Dies wiederum erklärt sich daraus, dass es grundsätzlich verschiedene Typen von TCP Retransmissions gibt, die – kurz erklärt – wie folgt aussehen:

>>> NEW TECH

525

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Die Zweitübertragung setzt am selben Sende-Offset an wie die Erstübertragung (im Event-Log von TraceMagic dargestellt mit dem Kürzel TCP ReTx [==] als Symbol für die Identität der so genannten TCP Sequence Number beider Pakete; siehe Abbildung 14.22). Diese Variante ist typisch für unidirektionale (Datei-) Übertragungen. Sie wird von herkömmlichen Analyzern erkannt. ■ Die Zweitübertragung setzt nicht am selben Sende-Offset an wie die Erstübertragung, sondern an einer Datenposition, die mitten in einem der vorigen TCP-Datenblöcke liegt (im Event-Log von TraceMagic dargestellt mit dem Kürzel TCP ReTx [] als Symbol für die Ungleichheit der so genannten TCP Sequence Number beider Pakete; siehe Abbildung 14.22). Diese Variante ist typisch für bidirektionales Transaktionsverhalten, etwa bei Authorization/Authentication oder Client/Slave Inter Process Communication (IPC). Sie wird von herkömmlichen Analyzern nicht oder nur höchst unzuverlässig erkannt (und falls doch, so werden sie schon gar nicht getrennt ausgewiesen). Unter anderem hierüber führte der Verfasser mit einem hochrangigen Vertreter eines der Hersteller von Hardware-Analyzern im Frühjahr 2002 einen höchst denkwürdigen Dialog, bei dem es um die Portierung von TraceMagic-Code in die Analyzer-Suite besagten Herstellers ging – ein Dialog, der am Ende dazu führte, dass der Verfasser das Gespräch völlig entnervt mit dem Hinweis abbrach, dass man mit Amateuren offenkundig keine Geschäfte machen könne. Davon ist bis heute nichts zurückzunehmen. Im Gegenteil: Das war noch freundlich ausgedrückt angesichts der Preise, die da bis heute genommen werden. ■ Die TCP Retransmission betrifft nicht Pakete mit Nutzdaten (so genannte TCP Sequences), sondern die Sitzungskommandos TCP-SYN, TCP-FIN und TCPRST. Diese Varianten sind typisch bei Server-Überlastung, HTTP-Sitzungen und Hacker-Attacken wie etwa beim Code-Red-Virus. Sie werden von herkömmlichen Analyzern nicht oder nur höchst unzuverlässig erkannt (und falls doch, so werden sie schon gar nicht getrennt ausgewiesen). Ansonsten gilt derselbe Kommentar wie beim vorigen Punkt. Das Erkennen der mit TCP ReTx [] gekennzeichneten TCP Retransmission wird erheblich begünstigt durch die hier in Rede stehende TCP ReTx Packet History (siehe Abbildung 14.21). Eine History-Größe mit 1.000 TCP-Headern (die in einem mitlaufenden Puffer nachgehalten werden) ist für LAN-Kommunikation i.d.R. ausreichend, da hier die Antwortzeiten kurz sind. Bei WANKommunikation muss damit gerechnet werden, dass die Antwortzeiten länger und somit die Zeitintervalle zwischen Erst- und Zweitübertragung länger sind. Sollten die Messdaten außer den WAN-Dialogen zusätzlich große Mengen an LAN-Daten enthalten, sollte zur zuverlässigen Erkennung der TCP Retransmissions über WANs die TCP ReTx Packet History auf den Wert von 10.000 TCPHeadern erhöht werden. ■

526

>>> NEW TECH

TraceMagic/SpiderMagic

Abbildung 14.22: Beispiel für die Darstellung verschiedener Typen von TCP Retransmissions im TraceMagic Event-Log: [==] versus []

Es ist zu berücksichtigen, dass diese Verfahren zwingend voraussetzen, dass die Trace-Dateien in chronologisch korrekter Reihenfolge durchlaufen bzw. verarbeitet werden. Dies führt beim LANdecoder32 (Triticom, USA) zu Problemen, weil die Zählung der Dateien im Dateinamen nicht durchgängig dreistellig ist, sondern erst einstellig (1-9), dann zweistellig (10-99), dann dreistellig (100255), was bei alphabetischer Sortierung zu einer falschen Reihenfolge führt. Hier sind über das TraceMagic-Modul TraceCounter die Zähler im Dateinamen durchgängig auf dreistellige Darstellung umzusetzen. Hieraus erklärt sich der Hinweis in der Fußzeile des Abfragefensters. Einstellungen zu Ergebnis-Trace-Datei und Event-Log Wie oben schon bei HostMagic erläutert, sollte bei der nun folgenden Abfrage bzgl. Ergebnis-Trace-Datei und Event-Log die erste Frage immer mit JA und die Abfrage bzgl. zusätzlicher Separat-Logs abhängig von der Datenmenge bzw. Verarbeitungsdauer beantwortet werden (siehe Abbildung 14.23).

Abbildung 14.23: Abfrage, ob die analyserelevanten LAN-Pakete herausgefiltert und neu abgespeichert werden sollen (hier sollte immer mit Ja geantwortet werden), und ob separate SpezialLogs geführt werden sollen (kann mit Nein beantwortet werden, da dies später nachgeholt werden kann)

Das Angebot, jedes Trefferpaket zusätzlich mit einem einfachen Text-Decoding in einer weiteren Ausgabe-Datei zu dokumentieren, sollte in der Regel mit >>> NEW TECH

527

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

NEIN abgelehnt werden, da es die Verarbeitungsgeschwindigkeit vermindert und die Ausgabedatenmenge erheblich erhöht (siehe Abbildung 14.24). Diese Funktion ist jedoch genau dann sinnvoll, wenn der Bearbeiter den OriginalAnalyzer nicht zur Verfügung hat oder doch mit seinem vorhandenen Analyzer den Trace sowie die Ergebnis-Dateien nicht einlesen kann. In diesem Falle sollte tatsächlich hilfsweise dieses einfache Packet-Decoding mitgenommen werden.

Abbildung 14.24: Abfrage, ob alle Trefferpakete mit einem einfachen Text-Decoding in einer zusätzlichen Log-Datei dokumentiert werden sollen. Diese Funktion ist i.d.R. nur bei FindMagic sinnvoll.

Letzte Abfrage vor Beginn der Analyse Sodann erfolgt auch bei SpiderMagic (wie bereits bei HostMagic beschrieben) die letzte Abfrage, die noch einen Abbruch möglich macht (siehe Abbildung 14.25).

Abbildung 14.25: Letzte Frage vor dem START: Soll die Analyse durchgeführt werden (mit den vorgenommenen Einstellungen) oder soll doch noch abgebrochen werden?

528

>>> NEW TECH

TraceMagic/SpiderMagic

14.3.2 Einblicke während der laufenden Analyse Zwar ist TraceMagic grundsätzlich darauf ausgelegt, dass man die Analyse startet und dann Kaffee trinken geht (oder am Feierabend nach Hause), um die Ergebnisse erst nach Rückkehr zur Kenntnis zu geben. Trotzdem gibt es gute Möglichkeiten, die wichtigsten Befunde schon während der laufenden Analyse einzusehen. Das Event-Log während der laufenden Analyse Das Event-Log der TraceMagic-Analyse ist immer in Dateien der folgenden Namenskonvention abgelegt: TM.HIT.FRAMES.*.LOG.TXT

Die darin dokumentierten LAN-Frames entsprechen exakt den Paketen, die aus den Original-Trace-Dateien herauskopiert und in die neu erzeugten ErgebnisTrace-Dateien hineingeschrieben wurden; diese neuen ergebnisgefilterten TraceDateien tragen den entsprechenden Namen: TM.HIT.FRAMES.*.ENC (oder .TRC,.ENF,.TRF, etc)

Die Event-Log-Datei stellt nicht nur eine chronologische Dokumentation der erkannten Ereignisse und Fehler dar, sondern auch den notwendigen Index, um die solcherart erkannten Ereignis-Frames auf die Originalfundstellen zurückführen zu können: Daher stehen am Anfang einer jeden Event-Log-Zeile die Nummer der Trace-Datei sowie die Nummer des jeweiligen LAN-Pakets (siehe Abbildung 14.26).

Abbildung 14.26: Das kleine Vorschaufenster zum Event-Log. Ein Mausklick auf den [>>>]-Button mit Brillen-Symbol öffnet das große Vorschaufenster zum Event-Log.

>>> NEW TECH

529

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Im TraceAnalysis-Fenster, das während der Analyse zu sehen ist und das die Fortschrittsbalken anzeigt, ist im Blatt [TRACE:EVENTS] ein kleines Vorschaufenster angesiedelt. Wird es mit START aktiviert, läuft das Event-Log in diesem Fenster mit (das verlangsamt jedoch auf die Dauer die Verarbeitungsgeschwindigkeit). Über die darüber liegende Auswahlleiste kann eingestellt werden, wie viele Textzeilen im Event-Log-Vorschaufenster dargestellt werden (100, 200, 500, 1.000, 10.000). Da dieses Vorschaufenster zugegeben klein ist (da es nur der kurzen Kontrolle dient), gibt es ein großes, zweites Vorschaufenster, das per Mausklick auf die [>>>]-Schaltfläche mit dem Brillen-Symbol geöffnet wird (siehe Abbildung 14.27).

Abbildung 14.27: Das ungefilterte Event-Log-Fenster

Das mit [* EVENTS] überschriebene Blatt enthält alle Event-Log-Zeilen und ist somit identisch mit dem späteren Inhalt der Event-Log-Datei TM.HIT. FRAMES.*.LOG.TXT (siehe oben). Die nachfolgenden Blätter zeigen nur gefilterte Teilmengen, je nach Protokoll (ARP, IP, ICMP, TCP, N.S. bzw. Name Services, SMB, NCP, HTTP) und je nachvoreingestelltem, benutzerdefiniertem Textfilter. Diese zwei möglichen Textfilter sind unter [LOG CONFIG] einzustellen. Werden die benutzerdefinierten Filter verwendet, erzeugt dies automatisch weitere Event-Log-Dateien im Unterverzeichnis des Analyse-Projekts, sodass die Ergebnisse festgehalten werden.

530

>>> NEW TECH

TraceMagic/SpiderMagic

Diese Quasi-Online-Logs (die während der laufenden Verarbeitung sichtbar sind bzw. erzeugt werden), sind letztlich verzichtbar, da nach Abschluss der Verarbeitung über das Event-Filter-Modul beliebige Textfilter gesetzt und sogar untereinander kombiniert werden können (was wesentlich wirkungsvollere Filter und daher bessere Ergebnisse zulässt).

Abbildung 14.28: Das auf IP vorgefilterte Event-Log-Fenster

Abbildung 14.29: Das auf TCP vorgefilterte Event-Log-Fenster

>>> NEW TECH

531

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.30: Das auf Name Services vorgefilterte Event-Log-Fenster

Abbildung 14.31: Das auf SMB vorgefilterte Event-Log-Fenster

Diese Event-Log-Vorschaufenster dienen hauptsächlich dazu, die ggf. längere Laufzeit der Analyse möglichst sinnvoll nutzen zu können, ohne nur zu warten. In diesem Sinne ist auch die Möglichkeit zu verstehen, die TraceStatisticsDatenbanken noch während der Laufzeit zu öffnen (siehe Abbildung 14.32).

532

>>> NEW TECH

TraceMagic/SpiderMagic

Auf eine Darstellung der TraceStatistics-Datenbank an dieser Stelle wird verzichtet, sie kommt noch ausführlich weiter unten zum Einsatz.

Abbildung 14.32: Schaltfläche mit Tabellen-Symbol zum Aufruf der TraceStatistics-Datenbank

Der TraceStatistics-Button (siehe Abbildung 14.32) taucht identisch am Ende des Analyse-Durchgangs im TraceHistory-Menü auf (siehe unten: TraceHistory: Datenbankfenster mit Sicht auf die Ergebnis-Dateien).

14.3.3 TraceReport: Erzeugung der Ergebnistabellen des AnalyseDurchgangs Am Ende eines jeden Analyse-Durchgangs werden die Statistiken und Tabellen auf die Festplatte geschrieben, teils in die TraceStatistics-Datenbanken (.DB), teils in .TXT- und .CSV-Dateien, ggf. auch in .HTML-Dateien.

Abbildung 14.33: TraceReport: Erzeugung der Ergebnistabellen am Ende des Analyse-Durchgangs. Hier (1): Ablage der Tabellen im Datenbankformat. Die Sternchen weisen auf bedenkliche Ereignisse und Fehler hin.

>>> NEW TECH

533

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.34: TraceReport: Erzeugung der Ergebnistabellen am Ende des Analyse-Durchgangs. Hier (2): Ablage der Tabellen in den Formaten .TXT und .CSV.

14.3.4 TraceHistory: Datenbankfenster mit Sicht auf die Ergebnis-Dateien Am Ende einer jeden TraceMagic-Analyse steht das aktuelle Fenster der TraceHistory-Datenbank, in der alle Analyse-Durchgänge festgehalten sind (siehe Abbildung 14.35). Es sind zu sehen: die Nummer des aktuellen Durchgangs (diese Nummer ist nichts weiter als die Datensatznummer in der TraceHistory-Tabelle), der vom Benutzer gewählte Vorgangstitel, der aktuelle Benutzername, Angaben zum Analyzer sowie der Name des Verzeichnisses, in dem die Trace-Dateien liegen, die mit dem Analyse-Durchgang verarbeitet wurden. Die beiden Tabellen darunter zeigen Dateien an: ■ ■

Tabelle links: Die originalen Trace-Dateien, die untersucht wurden Tabelle rechts: Die erzeugten Ergebnis-Dateien (mit Ausnahme der TraceStatistics-Datenbank, die über den entsprechenden Button mit dem Tabellen-Symbol geöffnet wird).

Über die Schaltfläche mit dem Tabellen-Symbol (siehe Abbildung 14.36) wird die TraceStatistics-Datenbank geöffnet, die für die TCP/IP-Analyse unverzichtbar ist.

534

>>> NEW TECH

TraceMagic/SpiderMagic

Abbildung 14.35: TraceHistory: Mit dieser Darstellung endet jeder Analyse-Durchgang.

Abbildung 14.36: Schaltfläche mit Tabellen-Symbol zum Aufruf der TraceStatistics-Datenbank

Ein Mausdoppelklick führt zum Öffnen entweder der ausgewählten TraceDatei (Tabelle links) oder der ausgewählten Ergebnis-Datei (Tabelle rechts). Einen unverstellten Blick auf die Dateien erhält man mit Aufruf des WindowsExplorers über die Schaltfläche mit dem Festplatten-Symbol (siehe Abbildung 14.37). Mit Mausklick auf diesen Button öffnet sich der Explorer im Verzeichnis, das die Ergebnis-Dateien samt die darin liegenden Unterverzeichnisse enthält.

Abbildung 14.37: Schaltfläche mit Festplatten-Symbol zum Aufruf des Windows-Explorers im AnalyseProjektverzeichnis

Die im Projektverzeichnis liegenden Dateien sind sämtlich über die rechte Tabelle des TraceHistory-Fensters sichtbar bzw. aufrufbar.

>>> NEW TECH

535

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.38: Der Inhalt des Projektverzeichnisses, in welchem sämtliche Ergebnis-Dateien des Analyse-Durchgangs von TraceMagic abgelegt werden

Wichtig ist es jedoch, die Funktion der beiden Unterverzeichnisse zu kennen, die nur über den Windows-Explorer erreichbar sind: ■ ■

Unterverzeichnis db: Hier liegen die Datenbanktabellen der TraceStatisticsDatenbank. Unterverzeichnis rc.files: Hier liegen (sofern vorhanden) die reconstructed files, also die aus Client/Server-Dialogen rekonstruierten Inhalte von übertragenen bzw. von Clients eingelesenen Dateien.

Die Dateien des db-Verzeichnisses in irgendeiner Weise manuell bearbeiten zu wollen, ist genauso zwecklos wie unplanmäßig: Hierfür ist das TraceStatisticsModul zuständig (siehe Abbildung 14.36). Die Dateien des rc.files-Verzeichnisses stellen ein wichtiges Analyse-Instrument dar, da hier die Inhalte verschiedenster Script-, INI- und Config-Dateien eingesehen werden können (mehr dazu siehe unten).

536

>>> NEW TECH

TraceMagic/SpiderMagic

Abbildung 14.39: Inhalt des db-Verzeichnisses mit den Dateien der TraceStatistics-Datenbanken

Abbildung 14.40: Inhalt des rc.files-Verzeichnisses mit den Dateien der rekonstruierten Übertragungsinhalte aus Client/Server-Dialogen

>>> NEW TECH

537

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

14.3.5 TraceStatistics: Die Datenbank der TCP/IP- und SMB-Statistiken Die TraceStatistics-Datenbank wird über die Schaltfläche mit dem TabellenSymbol geöffnet – entweder aus dem TraceHistory-Menü heraus oder aus der Button-Zeile im Hauptmenü von TraceMagic.

Abbildung 14.41: Schaltfläche mit Tabellen-Symbol zum Aufruf der TraceStatistics-Datenbank

Die TraceStatistics-Datenbank besteht aus verschiedenen Tabellen, die aus Gründen der Übersichtlichkeit nur durchnummeriert erscheinen, aber ohne ihren Titel. Um zur Tabellennummer auch den Titel einzusehen, fährt man mit der Maus über das links sichtbare, kleine Quadrat mit dem Doppelkreuz (#) und es öffnet sich ein kleines Popup-Fenster mit dem Inhaltsverzeichnis. Ein Mausklick auf einen anderen als den OK-Eintrag öffnet die entsprechende Tabelle.

Abbildung 14.42: Popup-Fenster mit der Inhaltsangabe der Tabellen

Die verschiedenen Tabellen sind: TabellenNummer

TabellenInhalt

0

Trace File Statistics

1

Analysis Summary: IP – ICMP – TCP

2

IP Host Top Talkers/IP – TCP – UDP –-ICMP

3

TCP-UDP Port Statistics/Services/Applications

4

IP Host Events plus Errors plus Statistics/Trace:Events/Knowledgebase

5

SMB Client Resource Requests/Server Error Returns

Tabelle 14.5: Inhalt der verschiedenen TraceStatistics-Tabellen

538

>>> NEW TECH

TraceMagic/SpiderMagic

Die Registerblätter mit dem Doppelkreuz-Zeichen (#) enthalten Tabellen, jene mit dem Tilden-Zeichen (~) Grafiken (Charts). Nun sollen die verschiedenen Tabellen vorgestellt und deren Inhalte bewertet werden – denn schließlich geht es jetzt darum, das Verhalten des Windows XPClients zu erkennen und zu bewerten. Tabelle 0: Trace File Statistics Die Tabelle 0 enthält einfache Statistiken: die Namen aller verarbeiteten TraceDateien (hier im Beispiel leider nur eine einzige), Protokollstatistiken und Paketgrößenstatistiken.

Abbildung 14.43: TraceStatistics/Tabelle 0: Alle verarbeiteten Trace-Dateien samt Protokoll- und Paketstatistiken (Tabelle)

>>> NEW TECH

539

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.44: TraceStatistics/Tabelle 0: Alle verarbeiteten Trace-Dateien samt Protokoll- und PaketStatistiken (Grafik: »Protocols«)

Tabelle 1: Analysis Summary (IP-ICMP-TCP) Die Tabelle 1 enthält eine vollständige Übersicht über alle Auffälligkeiten und Fehler, die TraceMagic in der TCP/IP-Analyse erkannt hat. Da hierbei auch seltene und allgemein nicht bekannte Ereignisse und Fehler berücksichtigt werden, versteht sich von selbst, dass mit einem Doppelklick die Knowledgebase-Datenbank geöffnet werden kann, die sämtliche von TraceMagic unterstützten TraceEvents (Trace-Vorkommnisse) enthält und erklärt. Daher sind die Statistikeinträge der Tabelle 1 mit Event-Codes versehen. Unter diesen Ereignisbezeichnungen sind die Vorkommnisse in der Wissensdatenbank (TraceMagic Knowledgebase) abgelegt bzw. aufzufinden.

540

>>> NEW TECH

TraceMagic/SpiderMagic

Abbildung 14.45: TraceStatistics/Tabelle 0: Alle verarbeiteten Trace-Dateien samt Protokoll- und Paketstatistiken (Grafik: »Frame Sizes«)

Es zeigen sich verschiedene Auffälligkeiten, dazu gehören 24 Ereignisse IP Packet IDs Disordered, was bedeutet, dass der begründete Verdacht besteht (der aber verifiziert werden muss), dass IP-Pakete in verdrehter Reihenfolge auf der Leitung waren (siehe Abbildung 14.46). Dies ist typisch für WAN-Kommunikation (IP-Pakete durchlaufen verschiedene Wege) oder für spezifische Erscheinungen der LAN-Kommunikation (FIFO-Fehler in Switches/Routern) oder Fehler im Load Balancing (pro-Packet anstatt pro-Session). Da diese Erscheinungen aus der Statistik allein nicht eingeordnet werden können, müssen diese Hinweise anhand des Event-Logs nachvollzogen und abschließend bewertet werden (siehe unten).

>>> NEW TECH

541

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.46: TraceStatistics/Tabelle 1: Es zeigt sich der Verdacht, dass IP-Pakete in verdrehter Reihenfolge festgestellt wurden (Event-Code = IP 5.2).

In ihrer Reihenfolge verdrehte IP-Pakete müssten eigentlich (nach der reinen Lehre gewissermaßen) harmlos sein. Die Erfahrung jedoch zeigt, dass bisweilen IP-Hosts trotzdem nervös reagieren können (so mehrfach beobachtet bei UnixServern mit Oracle-Datenbanken) und dass Ereignisse dieser Art Hinweise auf Instabilitäten in der WAN-Wolke sein können – Instabilitäten, die auch andere Folgen haben können wie beispielsweise TCP Retransmissions oder Sitzungsabbrüche. Somit ist klar, dass hier Arbeit wartet. Weiter unten – im Fortgang dieser Fallstudie – kommen wir darauf zurück. Ein paar Mal hat es ICMP-Meldungen gegeben mit der Mitteilung Destination Unreachable/Port Unavailable (siehe Abbildung 14.47). Dies kann harmlos sein (wenn beispielsweise Unix-Hosts auf WINS-Broadcasts an UDP-Port 137 reagieren); dies kann aber auch ein Hinweis auf ernstere Vorgänge sein, zum Beispiel in einer heterogenen Windows-Landschaft, in der alte Systeme (Win9x, WinME, WinNT4) und neue Systeme (Win2K, WinXP) nicht harmonieren, etwa mit Bezug auf LDAP (Port 389) oder Direkt-Host-Communication (Port 445).

542

>>> NEW TECH

TraceMagic/SpiderMagic

Abbildung 14.47: TraceStatistics/Tabelle 1: Einige ICMP-Meldungen des Typs Port Unavailable fallen auf (Event-Code = ICMP 3.3).

Insofern der aktuelle Anlass die Untersuchung eines Windows XP-Clients in einem LAN/WAN-Netzwerk betrifft, das sich zur Zeit in Migration befindet, wird auch hier klar, dass genauer hinzusehen sein wird (siehe Abbildung 14.48). ICMP-Meldungen des Inhalts Time Exceeded/Time-To-Live Expired (TTL = 0) sind immer ernst zu nehmen (siehe Abbildung 14.48), da sie als Hinweis auf Routing-Fehler zu gelten haben. Hier ist hauptsächlich zu prüfen, ob die Meldung von einem Router des eigenen Netzwerks kam (dann muss reagiert werden) oder fern aus dem Internet (dann kann es übergangen werden, zumal sowieso keine Einflussmöglichkeit bestünde). Auch hier wird im weiteren Fortgang der Fallstudie geklärt, worum es sich handelt (siehe Abbildung 14.49). Zweimal gab es TCP-RST-Signale (RST: Reset = Abbuch) in Folge vorangegangener TCP-SYN-Signale (SYN: Synchronize = Verbindungsaufbau). Dies wird gemeinhin als TCP Session Denial bezeichnet, also als die Ablehnung eines Antrags auf Einrichtung einer TCP-Sitzung (siehe Abbildung 14.49).

>>> NEW TECH

543

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.48: TraceStatistics/Tabelle 1: Mit ICMP: Time Exceeded ist ein ernstes Fehlerereignis in der Tabelle sichtbar (Event-Code = ICMP 11.0).

Ein solches Verhalten muss immer als auffällig erachtet werden, da jede der vier gängigen Ursachen Anlass gibt, genauer hinzusehen: 1. Ein Server ist überlastet und wehrt mit TCP-RST vorangegangene TCP-SYNVersuche ab. Der Client kann es erneut auf gut Glück zu versuchen, bis die Sitzung endlich zu Stande kommt. 2. Ein Client ruft einen Server-Port an, der nicht unterstützt wird. Hier ist nachzuforschen, warum der Client dies tut. In gemischten Windows-NetWare-Landschaften kommt es immer wieder vor, dass Clients verschiedene Windows-Server auf NetWare-Ports anrufen oder dass Clients verschiedene NetWare-Server auf Windows-Ports anrufen. 3. Ein Client ruft einen Server-Port an, der zwar generell unterstützt wird, nicht aber gegenüber dem anrufenden Client. Hier wäre zu prüfen, ob es Ausschlusstabellen auf dem Server gibt, die dem aktuellen Client verbieten, diesen Port zu nutzen. 4. Ein Client ruft einen Server-Port an und das TCP-SYN-Paket muss eine Firewall passieren. Ist dieser Ruf unzulässig, kann die Firewall mit TCP-RST antworten (muss aber nicht: viele Firewalls geben in solchen Fällen entweder ICMP-Meldungen zurück oder sogar überhaupt keine Meldung).

544

>>> NEW TECH

TraceMagic/SpiderMagic

Abbildung 14.49: TraceStatistics/Tabelle 1: Die Statistik weist 2x TCP Session-Denials auf (Event-Code = TCP 3.1) und 90x TCP ReTx (Event-Code = 2.1/2.2).

Keine dieser vier Möglichkeiten kann den Betrachter gleichgültig lassen. Also ist auch hier zu prüfen, was genau geschehen ist (siehe unten im weiteren Fortgang der Fallstudie). Weiterhin sehen Sie Statistikzähler zu TCP Retransmissions. TCP Retransmissions können ebenso harmlos wie interessant sein. Hier ist neben den reinen Zählerständen bzw. neben den reinen Mengenverhältnissen unter anderem von Belang, wie sich Vorkommnisse auf die verschiedenen Subtypen verteilen (siehe Abbildung 14.50). Wie bereits weiter oben dargestellt (siehe Abbildung 14.21 und Abbildung 14.22), gibt es unterschiedliche Typen von TCP Retransmissions und ihre genaue Unterscheidung ist alles andere als akademischer Zeitvertreib. In diesem Fall besteht der vorläufige Verdacht, dass ausgerechnet in der Phase von Authorization/Authentication die TCP-Verbindung des Windows XPClients zu einem seiner Server gestört sein könnte.

>>> NEW TECH

545

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.50: TraceStatistics/Tabelle 1: Die Statistik weist 90x TCP ReTx auf (Event-Code = 2.1/2.2); Window Size und Maximum Segment Size (MSS) sind in Ordnung.

Auch hierzu wird im Fortgang der Fallstudie weitere Erkenntnis gewonnen (siehe unten). Alle diese Statistikzähler der TraceStatistics-Datenbank für bis zu 65.500 IPHosts sind außerdem immer in den beiden folgenden Dateien enthalten: TM.SM.SpiderMagic.TABLES.~~IP~~.TXT TM.SM.SpiderMagic.TABLES.~~IP~~.Total.CSV TM.SM.SpiderMagic.TABLES.~~IP~~.Hosts.CSV

Die Text-Datei enthält sowohl die Gesamtstatistik wie auch die Einzelstatistiken (a) je Symptom und (b) je IP-Host. Einige Angaben sind ausschließlich in der Text-Datei enthalten, insofern sie sich einem Tabellenformat entziehen, so beispielsweise die Angabe, in welcher Trace-Datei und welchem LAN-Frame jeweils das erste und das letzte Paket eines jeden IP-Hosts enthalten sind, oder etwa die komplette Aufschlüsselung der TTL-Werte, mit denen die IP-Pakete eines jeden IP-Hosts am Messpunkt vorbeikamen.

546

>>> NEW TECH

TraceMagic/SpiderMagic

Abbildung 14.51: TraceStatistics/Tabellen 1 und 4: Dieselben Werte sind in TXT- und CSV-Dateien enthalten. Sterne (*) weisen auf Fehler oder Auffälligkeiten hin.

Die Text-Datei hat in der Praxis den großen Vorteil, dass sie sich schnell editieren und somit kommentieren und am Ende per E-Mail verschicken lässt. Jedoch muss bemerkt werden, dass auch die TraceStatistics-Datenbanken, erst einmal per WinZIP gepackt, so weit geschrumpft werden können, dass auch sie noch in den meisten Fällen per E-Mail verschickt werden können. Hier muss jeder Anwender am Ende selber seine eigene Praxis entwickeln. Tabelle 2: IP Host Top Talkers (IP-TCP-UDP-ICMP) Die Tabelle 2 enthält nicht wirklich diagnostische Angaben; sie gehört im weitesten Sinne zum Standardinventar einer jeden LAN-Analyse-Software und dient hier wesentlich dazu, die Top Talkers-Tabelle in Grafik-Charts zugänglich zu machen. Immerhin lehrt die Erfahrung, dass der Netzwerk-Praktiker beim Vortrag in der Chefetage bunte Bilder braucht, um einfache Zusammenhänge und Statistiken darzustellen. So ist es also auch hier (siehe Abbildung 14.52 bis 14.54).

>>> NEW TECH

547

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.52: TraceStatistics, Tabelle 2: IP Top Talkers mit den Protokollen IP, TCP, UDP, ICMP

Abbildung 14.53: TraceStatistics, Tabelle 2 (Grafik 1) der IP Top Talkers mit Prozentangaben

548

>>> NEW TECH

TraceMagic/SpiderMagic

Abbildung 14.54: TraceStatistics, Tabelle 2 (Grafik 2) der IP Top Talkers mit zusätzlicher Aufschlüsselung der Protokolle IP, TCP, UDP, ICMP

Tabelle 3: TCP-UDP Port Statistics (Services/Applications) Die Tabelle 3 enthält eine (fast) komplette Auswertung des TCP-Sitzungsverhaltens aller Netzwerk-Teilnehmer, deren Pakete am Messpunkt aufgezeichnet werden konnten. Diese Funktion trägt wesentlich dazu bei, dass einwandfrei arbeitende gestörten Applikationen schnell unterschieden werden können. Dies macht die Detailarbeit in der Analyse bzw. Bewertung wesentlich einfacher, da man weiß, wo man nicht zu suchen hat. Weiterhin sind die Hinweise auf Fehler bzw. Störungen auf Layer 4 dermaßen genau und umfangreich, dass in vielen Fällen hier schon weitgehende Schlussfolgerungen möglich sind. Mal wieder ist der Hinweis auf angeblich marktführende LAN-Analyzer nötig: Es ist bis heute kein Problem, 20.000 bis 40.000 Euro für ein Werkzeug auszugeben, das solche Statistiken nicht ausgibt. Man wundert sich immer wieder. (Dies gilt übrigens um so mehr für die Tabelle 3, die noch weit mehr Details anzeigt für bis zu 65.500 IP-Hosts). Doch zurück zur vorliegenden Tabelle. Es wird nicht zwischen einzelnen Netzwerk-Teilnehmern bzw. einzelnen Stationen unterschieden, sondern es wird nur auf Basis der UDP- und TCP-Ports gerechnet (siehe Abbildung 14.55).

>>> NEW TECH

549

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Dieselben Inhalte sind übrigens auch im CSV-Format in folgender Datei gespeichert: TM.PS.PortStatistics.TABLES.~~IP-TCP-UDP~~.TXT

Sie trägt die Datei-Endung .TXT, da sie u.a. dafür gedacht ist, nicht nur per Excel weiterverarbeitet, sondern auch per E-Mail verschickt zu werden – und zu diesem Zwecke muss sie unkompliziert lesbar sein. Wird sie in .CSV umbenannt, kann sie von z.B. von MS-Excel sofort erkannt werden (siehe Abbildung 14.62). In den einfachen Paket- und Byte-Statistiken wird sowohl UDP als auch TCP berücksichtigt, um das Sendevolumen auf Layer 4 insgesamt zu erfassen. Im Sitzungsverhalten sind nur die TCP-Dialoge berücksichtigt, da UDP keine eigenen Sitzungskommandos kennt und keine eigenständigen Mechanismen zur Datenflusskontrolle (wie etwa Retransmissions). Die Statistiken unterscheiden bei jedem TCP-Ereignis die Senderichtung in Rx und Tx. Aus Sicht des (oder der) Port-Inhaber sieht das etwa so aus: TCP ReTx [Tx] = 17 und TCP ReTx [Rx] = 39. Das bedeutet: Alle IP-Hosts, die über besagten TCP-Port gesendet haben, haben insgesamt (akkumuliert, zusammengerechnet) selber 17-mal TCP Retransmissions gesendet (Tx = Transmission) und dagegen 39 Mal TCP Retransmissions empfangen (Rx = Receive).

Abbildung 14.55: TraceStatistics, Tabelle 3/TCP-UDP Port Statistics: Das Kommunikationsverhalten einer jeden Applikation wird hier ausweislich ihres TCP-Ports auf TCP-Ebene nachgewiesen.

550

>>> NEW TECH

TraceMagic/SpiderMagic

Auf diese Weise lässt sich über das Sortieren der Tabelle schnell und unkompliziert herausfinden: ■ ■

■

Welche Applikation hatte (der einzelnen Teilnehmer ungeachtet) das höchste Sende- und Empfangsvolumen aus der Sicht der Server? Welche Applikation hatte (der einzelnen Teilnehmer ungeachtet) die meisten Session Denials, Retransmissions, Window Size Zero-Symptome, etc., etc.? Gehen bestimmte Ereignisse wie TCP Retransmissions eher von den Clients aus oder von den Servern (Rx, Tx)?

Wer einfach und schnell die »kranken« Applikationen (bzw. solche, die unter Paketverlusten etc. zu leiden haben) herausfinden will, blättert in der Tabelle ganz nach rechts und sortiert die vorletzte Spalte: Alle Services, die ein Sternchen (*) gesetzt haben, weisen Auffälligkeiten und/oder Fehler auf (siehe Abbildung 14.56).

Abbildung 14.56: TraceStatistics, Tabelle 3/TCP-UDP Port Statistics: Jeder Stern zeigt Auffälligkeiten oder Fehler in der TCP-Kommunikation dieser Applikation an.

Selbstverständlich besteht Bedarf, etwaiges Fehlverhalten der gesamten Applikation(sklasse) am Ende auf die einzelnen IP-Teilnehmer herunterbrechen zu können. >>> NEW TECH

551

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Dies geschieht wenig später in der folgenden Tabelle 4, die sämtliche Symptome ebenfalls auflistet (und noch mehr darüber hinaus), dieses Mal aber nicht aus Basis der TCP-Ports, sondern der IP-Absenderadressen (siehe unten).

Abbildung 14.57: TraceStatistics, Tabelle 3/TCP-UDP Port Statistics: NCP (1)

Ein Mausdoppelklick auf eine Tabellenzeile führt dazu, dass für die just aktuell gewählte Applikation(sklasse) bzw. den entsprechenden TCP-Port eine Textausgabe der Statistiken ausgegeben wird. Diese Textausgabe ist wesentlich leichter lesbar, wenn man eine einzelne Applikation(sklasse) in den Blick nehmen will, zumal nicht mehr nur das Sternchen (*) die Applikation insgesamt als auffällig oder gestört einstuft, sondern zudem die einzelnen Symptome markiert, die als auffällig oder fehlerhaft verdächtig sind. In Abbildung 14.57 ist die Textausgabe (Ausschnitt 1) für den TCP-Port 524 zu sehen (Novell NetWare, NCP-over-TCP); das Sternchen (*) im Tabellenkopf zeigt an, dass es Auffälligkeiten gibt. In Abbildung 14.58 ist zu sehen, dass die Auffälligkeit in einer einzigen TCP Retransmission besteht, die von einem der NCP-Server ausgegangen war. Hier darf sicher angenommen werden, dass es sich um ein vernachlässigenswertes Ereignis handelt.

552

>>> NEW TECH

TraceMagic/SpiderMagic

Abbildung 14.58: TraceStatistics, Tabelle 3/TCP-UDP Port Statistics: NCP (2)

Da ansonsten keine weiteren Auffälligkeiten oder Fehler nachgewiesen sind, darf die Client/Server-Kommunikation über NCP als gesund und unauffällig eingestuft werden. Dies ist im Sinne unserer Fallstudie, die ja einen Windows XP-Client in einer heterogenen Windows/NetWare-Umgebung untersuchen will, von erheblichem Belang: Es kann jetzt schon einmal ausgeschlossen werden, dass es auf Ebene der TCPSitzungs- und Datenflusssteuerung bei NetWare-Dialogen zu Störungen gekommen wäre. Ein Blick auf den TCP-Port 139 (SMB: Server Message Block; Windows, OS/2, Samba) zeigt, dass schon eher Anlass zur Besorgnis besteht (siehe Abbildung 14.59). Zunächst erscheint das Sitzungsverhalten ordnungsgemäß (sechs Sitzungen mit TCP-SYN beantragt, ebenfalls sechs mit TCP-SYN-ACK bestätigt, eine Sitzung mit TCP-FIN beendet). Dann aber zeigt sich: Viermal wurden TCP-RST-Signale von den SMB-Servern empfangen (Rx); viermal also haben Windows-Clients gegenüber ihren Windows-Servern die Sitzung mit dem Abbruchsignal TCP-RST beendet.

>>> NEW TECH

553

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.59: TraceStatistics, Tabelle 3/TCP-UDP Port Statistics: SMB

Weiterhin sendeten die Windows-Server 27-mal TCP Retransmissions – wobei sich die Frage stellt, ob sich zwischen den via TCP-RST mitgeteilten Abbrüchen der Clients und den TCP-ReTx der Server ein Zusammenhang herstellen lässt (oder nicht). In jedem Falle ist klar: Hier muss geprüft werden, was im Einzelnen vorgegangen ist und welche IP-Hosts es jeweils betroffen hat. Hierzu erfahren Sie später mehr (siehe unten). Die erste Grafik zeigt schnell und bunt die Top Talkers unter den Applikationen (siehe Abbildung 14.60). Auch wenn bunte Kuchen- und Balkendiagramme schnell (und meistens zu Recht übrigens) im Verdacht stehen, einfach nur Schau zu machen, so ist es doch hilfreich, schnell zu überblicken, welche Applikationen hauptsächlich die Datenlast auf dem Netzwerk verursachen.

554

>>> NEW TECH

TraceMagic/SpiderMagic

Abbildung 14.60: TraceStatistics, Tabelle 3/TCP-UDP Port Statistics: Top Talkers auf Applikationsebene: Welche Services bzw. Ports haben das meiste Paketaufkommen?

Die zweite Grafik macht sichtbar, welche erheblichen Fehler bzw. Störereignisse in den TCP-Dialogen auf welchen Ports aufgetreten sind (siehe Abbildung 14.61). Die Port-Statistiken werden (wie bereits oben festgestellt) nicht nur als Datenbank im TraceStatistics-Modul sichtbar, sondern auch in der folgenden ReportDatei: TM.PS.PortStatistics.TABLES.~~IP-TCP-UDP~~.TXT

Sie ist im CSV-Format gehalten, ist aber dennoch mit der Endung .TXT gehalten, damit sie in jedem beliebigen Texteditor schnell lesbar ist. So kann sie einfach editiert bzw. kommentiert und sodann per E-Mail verschickt werden (siehe Abbildung 14.62).

>>> NEW TECH

555

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.61: TraceStatistics, Tabelle 3/TCP-UDP Port Statistics: Welche Services bzw. Ports haben die meisten Window Size Zero-Symptome und Verbindungsabbrüche (TCP-RST)?

Abbildung 14.62: TraceStatistics, Tabelle 3/TCP-UDP Port Statistics: Die Tabelle der TCP-Statistiken wird auch im CSV-Format als Datei abgespeichert.

Tabelle 4: IP Host Events/Errors/Statistics Waren die Ergebnisse der Tabelle 3 noch ohne Rücksicht auf einzelne IP-Teilnehmer nur auf die Applikationen bzw. TCP-Ports bezogen, um schnell eine umfassende Übersicht zu erhalten, so liefert die Tabelle 4 Details anderer Art.

556

>>> NEW TECH

TraceMagic/SpiderMagic

Die Tabelle 4 enthält die Einzelnachweise für jeden einzelnen IP-Host, dessen LAN-Pakete am Messpunkt vorüberkamen und aufgezeichnet wurden (siehe Abbildung 14.63). Es können bis zu 65.600 IP-Hosts in dieser Datenbank mit den Statistiken ihrer Merkmale, Auffälligkeiten und Fehler dokumentiert werden. Auch hier (wie bei Tabelle 3) werden die Ergebnisse zudem in Text- und CSV-Dateien ausgegeben, um Unabhängigkeit vom TraceStatistics-DatenbankModul zu gewährleisten (siehe unten, Abbildung 14.70). Erneut muss der Hinweis erfolgen, dass die etablierten Hersteller in den 10 bis 20 Jahren ihrer Existenz auf dem Weltmarkt nichts dergleichen zu Stande gebracht haben. Offenkundig wirkt das Lesen und Implementieren von RFCs allzu einschläfernd – wie sonst kann man sich das lange Nichtstun dieser Hersteller erklären. Bereits im Dezember 2001 stellten Synapse:Networks eine CSV-Datei sowie die daraus abgeleitete Excel-Datei ins Internet mit dem vollständigen AnalyseNachweis von 22.661 IP-Hosts (mit über 200 Fehler- und Ereigniszählern je einzelnen IP-Host!) aus einem der größten WANs Deutschlands (selbstverständlich wurden über das TraceAnon-Modul die IP-Adressen zuvor anonymisiert). Die Veröffentlichung dieser fast schon gigantischen Excel-Tabelle wird zum Zeitpunkt des Erscheinens dieses Buchs im Frühjahr 2003 schon bald anderthalb Jahre her sein. Eine Reaktion der etablierten Hersteller erfolgte nicht wirklich: Die einzig nennenswerte Reaktion war die eines dieser Hersteller mit der Anfrage, ob TraceMagic-Code eingekauft werden könne. Die Erfolglosigkeit und letztlich auch die Sinnlosigkeit der nachfolgenden Verhandlungen wurden an dieser Stelle schon mehrfach dargestellt. Wer immer unter den geschätzten Lesern so einen 20.000-Euro-Analyzer sein Eigen nennt, möge doch mal versuchen, derart detaillierte Information aus Trace-Dateien herauszuholen. Vermutlich wird nach Tagen aufopferungsvollen Selbstversuchs nur das frustrierte Scheitern stehen. Nicht umsonst hat sich der Verfasser dieser Zeilen vor Jahren entschieden, die eigene berufliche Zukunft nicht mehr von der Schlafmützigkeit der großen USHersteller abhängig zu machen, sondern stattdessen auf die eigene Entwicklung von TraceMagic zu setzen. Das Download ermöglicht jedem, die Aussagekraft einer solchen Tabelle nachzuvollziehen: http://www.synapse.de/tracemagic/tm.power.htm

Die Tabelle 4 mit den IP-Host-Einzelnachweisen unterteilt sich in verschiedene Untertabellen: ■

Hosts: Hier sind die IP-Adressen enthalten sowie Statistiken über die Anzahl der zur IP-Adresse gehörenden MAC-Adressen (können auch Router-MACs sein); über die Anzahl der gesendeten IP-/TCP-/UDP-/ICMP-Pakete; über den Fehlerstatus, dargestellt durch Sternchen (*); über die Zahl der mit Auffälligkeiten und Fehlern verbundenen IP-Pakete (Event Packets).

>>> NEW TECH

557

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.63: TraceStatistics, Tabelle 4 (IP Host Statistics): x

■ ■ ■

Mit Mausklick auf den Spaltentitel mit dem Sternchen (*) wird die Tabelle automatisch nach Fehlerstatus sortiert: je mehr Sternchen, umso schlimmer der Befund. Der Fehlerstatus ist jedoch qualitativ, macht sich also fest an der Art der Fehler. Die quantitative Einordnung erfolgt über die letzte Spalte rechts (Event Packets). IP: Alle Auffälligkeiten/Fehler, die in IP-Paketen gefunden wurden TCP: Alle Auffälligkeiten/Fehler, die in TCP-Paketen gefunden wurden ICMP: Alle Hinweise und Fehler, die sich aus ICMP-Meldungen ergaben

Wird aus der Hosts-Tabelle in eine der Protokolltabellen gewechselt, erscheint nur eine einzelne Tabellenzeile, nämlich die mit den zur aktuell ausgewählten IP-Adresse. Sollen die Daten aller IP-Hosts in den Protokolltabellen dargestellt werden, muss die Tabellenverknüpfung zwischen der Haupttabelle (Hosts) und der jeweiligen Protokolltabelle aufgelöst werden. Dies geschieht über die Schaltfläche mit dem Symbol der aufgetrennten Kettenglieder (siehe Abbildung 14.66 und zugehörige Erklärung).

558

>>> NEW TECH

TraceMagic/SpiderMagic

Hinter dem Registerblatt mit der Beschriftung [/... ] verbirgt sich die Textdarstellung für den jeweils aktuell angewählten IP-Host. Ein Mausdoppelklick in jeglicher Tabellenzeile führt automatisch dorthin (siehe Abbildung 14.64).

Abbildung 14.64: TraceStatistics, Tabelle 4 (IP Host Statistics): x

Abbildung 14.64 zeigt den Textauszug für die Adresse IP = 192.168.250.97: Dieser IP-Teilnehmer, der offenkundig ein Router ist, hat eine ICMP-Meldung zu verantworten mit dem Hinweis, dass ein Paket verworfen werden musste, weil dessen TTL-Wert auf Null gefallen war. Hier zeigt sich, dass dringend Nachforschung geboten ist: Denn wenn es sich nicht um einen Internet-Router handelt (für den man nicht selber zuständig ist), sondern um einen der eigenen Campus-Router, so kann es sich um selbst zu verantwortende Fehler in der Routing-Konfiguration handeln. Abbildung 14.65 zeigt Auffälligkeiten bei der Adresse IP = 192.168.2.195: Die Pakete dieses Absenders trafen am Messpunkt häufig in verdrehter Reihenfolge ein, und von 13 Vorkommnissen dieser Art werden insgesamt 11 als wahrscheinlich fehlerhaft eingestuft. Hier ist jeweils genau zu unterscheiden, ob die betroffenen IP-Pakete über WAN-Leitungen liefen (wo derartige Erscheinungen auf Instabilitäten in der WAN-Wolke zurückzuführen sein können) oder nur über das Campus-LAN (was dann zu völlig anderen Schlussfolgerungen führen kann).

>>> NEW TECH

559

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.65: TraceStatistics, Tabelle 4 (IP Host Statistics): x

Weiter unten, bei der genauen Betrachtung im Event-Log von TraceMagic, werden wir hierauf zurückkommen. Abbildung 14.66 zeigt, wie ganz einfach nachvollzogen werden kann, ob das zuletzt gesehene Symptom – in ihrer Reihenfolge verdrehte IP-Pakete – viele IPTeilnehmer betrifft und ggf. in welchem Ausmaß. Hierzu wird die Verknüpfung zwischen Haupttabelle (Hosts) und Protokolltabelle (IP) über einen Mausklick auf die Schaltfläche mit dem Symbol der getrennten Kettenglieder aufgehoben, damit die Daten aller IP-Teilnehmer angezeigt werden (und nicht nur die der aktuell ausgewählten Adresse IP = 192.168.2.195). Sodann zeigt sich nach einem Mausklick auf den Spaltentitel (was ein Sortieren nach Zahlenwert zur Folge hat), dass dieses Symptom nicht zu oft vorkommt und im Besonderen die aktuelle Adresse IP = 192.168.2.195 betrifft. Auffällig jedoch ist, dass die drei nachfolgenden IP-Teilnehmer aus einem anderen IPSubnetz stammen. Das kann Zufall sein (muss aber nicht). Immer wieder wichtig ist die Betrachtung der TCP Retransmissions. Auch hier kann schnell und einfach nachvollzogen werden, welche IP-Teilnehmer die meisten TCP Retransmissions vorgenommen haben.

560

>>> NEW TECH

TraceMagic/SpiderMagic

Abbildung 14.66: TraceStatistics, Tabelle 4 (IP Host Statistics): x

Abbildung 14.67: TraceStatistics, Tabelle 4 (IP Host Statistics): x

>>> NEW TECH

561

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Will man wissen, welchen anderen IP-Teilnehmern gegenüber diese TCP Retransmissions stattfanden, so ist über das EventFilter-Modul das Event-Log dergestalt zu filtern, dass man die Textmerkmale 22.64.4.2 und ReTx kombiniert – schon kommt ein gefiltertes Event-Log heraus, das alle TCP ReTx des IP-Hosts 22.64.4.2 ausweist. Wie derartige Filter auf das Event-Log von TraceMagic zu setzen sind, wird weiter unten ausführlich dargestellt. In den Protokolltabellen gibt es die Schaltfläche mit der Aufschrift TRACE:EVENTS samt einer Brille. Ein Mausklick hierauf ruft die TraceEvent-Knowledgebase auf (siehe Abbildung 14.68).

Abbildung 14.68: TraceStatistics, Tabelle 4 (IP Host Statistics): Bei Aufruf der TraceEvents-Knowledgebase werden nur genau die Fehler und Ereignisse angezeigt, welche die oben links eingeblendete IP-Adresse (hier: 22.64.4.2) betreffen.

Wird mit Mausklick auf die TRACEEVENTS-Schaltfläche die Knowledgebase aufgerufen (siehe Abbildung 14.68), so erscheinen nicht alle Datenbankeinträge dieser Tabelle, sondern nur genau die, welche mit der aktuell ausgewählten und oben links angezeigten IP-Adresse zu tun haben (hier: 22.64.4.2). In der unteren Hälfte des TRACEEVENTS-Fensters sind vier Textfelder zu sehen, mit denen es folgende Bewandtnis hat: 1. System Memo (1): Diese Textbox enthält die vom Hersteller (Synapse:Networks) bereitgestellten Knowledgebase-Texte; sie ist für die Anwender nicht editierbar sondern nur lesbar. Aktualisierte Fassungen sind mit jedem Update via Internet erhältlich (www.tracemagic.net).

562

>>> NEW TECH

TraceMagic/SpiderMagic

2. System Memo (2): Wie System Memo (1), jedoch zurzeit noch nicht in Gebrauch 3. User Memo: Textbox für den TraceMagic-Anwender. Hier können alle eigenen Angaben editiert werden. Diese Angaben können zudem exportiert und anderen TraceMagic-Anwendern zur Verfügung gestellt werden. 4. 3rd Party Memo: Hier landen alle Texte, die von anderen TraceMagicAnwendern stammen und in die lokale TraceMagic-Datenbank importiert wurden. Die eigene User Memo-Textbox bleibt also immer unangetastet, wenn die Texte Dritter eingeladen werden. Ein Mausdoppelklick auf eine Tabellenzeile öffnet das große Textfenster (TRACE:MEMO) mit dem Inhalt der gerade angewählten Textbox, hier System Memo (1).

Abbildung 14.69: TraceStatistics, Tabelle 4 (IP Host Statistics)/TraceEvent-Knowledgebase: Ein Mausdoppelklick in dem Knowledgebase-Fenster öffnet ein zusätzliches Textfenster mit den Erklärungen zum aktuellen Eintrag.

Abbildung 14.69 zeigt das System Memo (1) mit den Erklärungen zum TCP-RSTSignal; eigene Ergänzungen hierzu müssen im User Memo eingegeben werden.

>>> NEW TECH

563

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.70: TraceStatistics, Tabelle 4 (IP Host Statistics): Alle Einzelnachweise bis max. 65.500 IPHosts sind zudem in lesbarer Text-Datei gespeichert sowie zusätzlich im CSV-Format.

Abbildung 14.70 zeigt den Einzelnachweis zu IP-Host 22.64.4.2, dieses Mal jedoch nicht gesehen durch das Datenbankfenster des TraceStatistics-Moduls, sondern aus der parallel erzeugten Text-Datei (siehe unten). Ergebnis: Die IP-Befunde sind unauffällig, desgleichen die ICMP-Meldungen; die TCP-Befunde jedoch geben Anlass, weitere Nachforschungen anzustellen (was im weiteren Verlauf dieser Fallstudie geschieht, siehe unten): TCP Retransmissions, TCP-RST-Signale, TCP Session Denials – das sieht nicht so sehr gesund aus! Es dürfte auffallen, dass nicht nur die Datenbank als Quelle der Erkenntnis zur Verfügung steht, sondern auch Text-Dateien. Das hat gute Gründe.

564

>>> NEW TECH

TraceMagic/SpiderMagic

Alle Statistikzähler der TraceStatistics-Datenbank für bis zu 65.500 IP-Hosts sind parallel immer in den folgenden Dateien enthalten: TM.SM.SpiderMagic.TABLES.~~IP~~.TXT TM.SM.SpiderMagic.TABLES.~~IP~~.Total.CSV TM.SM.SpiderMagic.TABLES.~~IP~~.Hosts.CSV

Die Text-Datei enthält sowohl die Gesamtstatistik wie auch die Einzelstatistiken (a) je Symptom und (b) je IP-Host. Einige Angaben sind ausschließlich in der Text-Datei enthalten, insofern sie sich einem Tabellenformat entziehen, so beispielsweise die Angabe, in welcher TraceDatei und welchem LAN-Frame jeweils das erste und letzte Paket eines jeden IPHosts enthalten sind oder etwa die komplette Aufschlüsselung der TTL-Werte, mit denen die IP-Pakete eines jeden IP-Hosts am Messpunkt vorbeikamen. Die Text-Datei hat in der Praxis den großen Vorteil, dass sie sich schnell editieren und somit kommentieren und am Ende per E-Mail verschicken lässt. Jedoch muss bemerkt werden, dass auch die TraceStatistics-Datenbanken, erst einmal per WinZIP gepackt, so weit geschrumpft werden können, dass auch sie noch in den meisten Fällen per E-Mail verschickt werden können.

Abbildung 14.71: TraceStatistics, Tabelle 4 (IP Host Statistics): Die auffälligsten IP-Hosts werden sowohl im Grafik-Chart wie auch nebenstehender Rangliste aufgeführt.

>>> NEW TECH

565

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Die in Abbildung 14.71 dargestellte Grafik stellt gut sichtbar die Kummerkandidaten unter den IP-Teilnehmern heraus. Die Rangfolge richtet sich nach dem Fehlerstatus, wie oben zu Beginn dieses Abschnitts ausführlich dargestellt. Tabelle 5: SMB Client Resource Requests/Server Error Returns Die Tabelle 5 enthält den Nachweis aller Server-Ressourcen (Shares, Dateien, logische Prozesse), die zwar von Windows-Clients via SMB-Protokoll auf Windows-Servern gesucht, von diesen jedoch nicht herausgegeben wurden (siehe Abbildung 14.72). Für diese Ereignisse kann es verschiedene Gründe geben: ■ ■ ■ ■

Der Client sucht die richtige Ressource auf dem falschen Server. Der Client sucht die richtige Ressource zwar auf dem richtigen Server, aber im falschen Verzeichnis. Der Client sucht eine Ressource, die es gar nicht gibt (und deswegen ist es auch egal, auf welchem Server er sie sucht). Der Client sucht die richtige Ressource auf dem richtigen Server im richtigen Verzeichnis, aber der Server gibt sie trotzdem nicht heraus, ggf. aus Gründen fehlender Rechte oder dergleichen mehr.

Will man nachforschen, welche Clients und Server an bestimmten Fehlzugriffen beteiligt sind, setzt man auf das Event-Log von TraceMagic einen Textfilter (im EventFilter-Modul, siehe unten), etwa auf der Suche nach der in Abbildung 14.74 näher betrachteten Datei NI010094.SEC – das im Ergebnis ausgeworfene, gefilterte Event-Log zeigt alle Fehlzugriffe chronologisch mit Angabe der jeweiligen Rechneradressen und zwar ungeachtet des Protokoll-Stapels. ■

■ ■ ■ ■ ■

Da SMB über verschiedene Protokoll-Stapel arbeiten kann, ist die Bemerkung nicht unwichtig, dass TraceMagic die folgenden SMB-Varianten unterstützt: SMB über LLC plus NetBIOS (allgemein NetBEUI genannt) SMB über IPX (eigentlich ein NetWare-Protokoll) SMB über TCP/IP (NetBT oder kurz NBT genannt) SMB über Banyan Vines IP (eine inzwischen fast ausgestorbene Variante) Im Falle von NetBEUI und IPX wird im Event-Log bei den beteiligten Rechnern nicht die IP-Adresse angegeben, sondern die MAC-Adresse oder die IPX-Adresse.

Die in Abbildung 14.72 dargestellte Tabelle zeigt (von links nach rechts) zunächst die laufende Datensatznummer, dann Fehlerhäufigkeit und Fehlerstatus; dann folgt als Nächstes der Ressourcen-Pfad, wie er in den LAN-Paketen tatsächlich auftrat, und in den nächsten drei Spalten ist dieser Ressourcen-Pfad in Pfad, Datei-Name und Namenserweiterung (Datei-Typ) aufgespalten. Im vorliegenden Beispiel ist die Tabelle nach Fehlerstatus sortiert und es sind zwei Einträge mit dem Statuszähler 3 vorhanden: ■ ■

566

NiAgnt32.exe.Local NiAgnt32.exe.Manifest

>>> NEW TECH

TraceMagic/SpiderMagic

Abbildung 14.72: TraceStatistics, Tabelle 5 (SMB Denied Resources): Völlig unzulässige Suche nach NiAgnt32.exe.Manifest und NiAgnt32.exe.Local. Solche Kombinationen sind nicht regulär.

Keine Frage – das haben Sie nicht erwartet! Ausführbare EXE-Dateien, deren Datei-Name um einfallsreiche Ergänzungen erweitert sind! Kein Problem, Windows macht’s möglich. Zunächst einmal darf festgestellt werden: Es verwundert nicht, dass auf diese Anfragen hin kein Server bereit war, das Vorhandensein dieser Dateien zu bestätigen – weil es sie nicht gibt. Jedoch muss dem werten Leser an dieser Stelle gesagt werden: Das war ja noch gar nichts. Das war erst der Anfang. Im nachfolgenden Layer-7-Kapitel werden Beispiele folgen, die es erst richtig in sich haben. Der Unterhaltungswert mancher Client-Anfrage ist größer als ein 4-Wochen-Ticket fürs Multiplex-Kino einer mitteldeutschen Großstadt! Wir werden ja sehen. Sichtbar jedenfalls wird hier schon, dass Windows-Clients bisweilen dazu neigen, Dateinamen mit allerlei Mutationen zu beglücken – mit der Folge, dass derartige Zugriffe ins Leere laufen. Hier hat es die Datei NiAgnt32.exe des Net-Installers erwischt – ein Dienst, der dafür sorgen soll, dass die Clients immer mit den aktuellsten Dateien ausgestattet sind.

>>> NEW TECH

567

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.73: Das Script-File LclFil2K.cfg (von TraceMagic über die rc.files-Funktion rekonstruiert), das letztlich die Aktivitäten von NetInstaller lenkt

Wir dürfen jetzt schon vermuten, dass es wieder einen Anwender mehr gibt, der stöhnt: »Das Netzwerk ist langsam.« Nun, richtig daran ist, dass die Datei-Holung wohl unter solchen Bedingungen länger dauern dürfte, als dem Anwender recht sein kann. Aber auch normale Dateien werden zwar gesucht, aber nicht gefunden, so zum Beispiel: ■ ■

\NTCONFIG.POL \SECUR32.DLL

Es darf angenommen werden, dass diese Dateien – wenn es sie denn geben sollte – möglicherweise nicht im (logischen) Hauptverzeichnis des Server-Shares liegen, sondern in einem der Unterverzeichnisse, und daher auch nicht gefunden werden (sofern sie überhaupt auf dem richtigen Server gesucht wurden). Klar ist, dass dies Anlass zu weiteren Nachforschungen gibt (siehe unten).

568

>>> NEW TECH

TraceMagic/SpiderMagic

Aber auch Zugriffe auf Shares laufen ins Leere, weil sie auf Protokollebene in völlig verbotener Weise wie normale Dateizugriffe abgesetzt werden: ■ ■

\VI-ED-NI01\NI5$ \NI-ED-NI02\NI5$

Wenn schon der Zugriff auf ein Windows-Share initialisiert werden soll, dann in der UNC-Notation mit Doppel-Backslash (\\NI-ED-NI01\NI5$) und dann eben nicht mit dem SMB-Code 0x32 (wie bei Dateizugriffen üblich und wie hier geschehen). Die SMB-Funktions-Codes und Zugriffstypen sind in der Tabelle 5 ebenfalls ausgewiesen und in Abbildung 14.74 zu sehen. Alles in allem zeigten sich im Trace des zu prüfenden Windows XP-Clients: viele Fehler, zum Teil sogar gravierende Fehler und sogar noch reichlich bizarre dazu. Die Hoffnung, dass nach Windows NT 4 die Szenerie von den übelsten Fehlern der 90-er Jahre bereinigt sein würde, wenn zu Windows 2000 oder Windows XP migriert wird, muss tatsächlich als nicht ganz realistisch eingestuft werden.

Abbildung 14.74: TraceStatistics, Tabelle 5 (SMB Denied Resources): x

Wird die Spalte [File Name/Resource Name] alphabetisch sortiert, kann ganz leicht in der links davon liegenden Spalte [\Path Directory]/[\\UNC Resource Path] abgelesen werden, in welchen verschiedenen Verzeichnissen eine jede Datei (Resource) vergebens gesucht wurde (hier NI010094.SEC).

>>> NEW TECH

569

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Schade, dass die aktuelle Fallstudie nicht alles zugleich bietet: Sonst würden wir uns – wie in fast allen Fällen üblich – an den vielen, völlig verschiedenen Pfaden erfreuen, in denen Clients verzweifelt nach DESKTOP.INI suchen oder sogar schon mal nach NTUSER.DAT – alles ist möglich! Doch, nicht verzagen: Derlei wunderschöne Beispiele folgen im nächsten Layer-7-Kapitel nach der Fallstudie.

Abbildung 14.75: TraceStatistics, Tabelle 5 (SMB Denied Resources): Die am häufigsten von Clients gesuchten, von Servern aber nicht gegebenen SMB-Ressourcen in der Rangliste

Welche SMB-Ressourcen zwischen Windows-Client und Windows-Server am häufigsten strittig waren (insofern sie von den Clients zwar beantragt, von den Servern aber nicht gegeben wurden), ist in Abbildung 14.75 mit einer Rangliste leicht ablesbar.

14.4 TraceMagic/Event-Log und EventFilter Wir haben in Betrachtung der bislang gebotenen Informationen viele Hinweise und Nachweise zu Auffälligkeiten und Fehlern erhalten. Nun geht es daran, diesen Hinweisen nachzugehen und sie herunterzubrechen auf einzelne, konkrete Vorgänge sowie auf die daran beteiligten Clients und Server. Hierzu tut man gut daran, aus dem TraceHistory-Menü heraus das EventFilterModul aufzurufen (Trace:Events/Event:Filter). Das Event-Log von TraceMagic liegt in der folgenden Datei: TM.HIT.FRAMES.01.~~001.LOG.TXT

570

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

Dies gilt aber nur eingeschränkt: Nicht alle Log-Einträge müssen in dieser einen Datei stehen. Bei mehreren Gigabytes an Messdaten und vielen Ereignissen und Fehlern darin würde eine Datei gar nicht ausreichen, um die Log-Einträge aufzunehmen. Entsprechend werden ggf. mehrere Event-Log-Dateien erzeugt: TM.HIT.FRAMES.01.~~001.LOG.TXT TM.HIT.FRAMES.01.~~002.LOG.TXT TM.HIT.FRAMES.01.~~003.LOG.TXT : : : : TM.HIT.FRAMES.01.~~999.LOG.TXT

In einer einzelnen Log-Datei kann man noch ganz einfach im Texteditor mit der Suchfunktion die gewünschten Fundstellen aufspüren. Liegen aber erst einmal zehn oder zwanzig Log-Dateien vor, ergibt dies keinen Sinn mehr. Entsprechend bedient man sich dann der EventFilter-Funktion, da diese über alle vorhandenen Event-Log-Dateien hinweg arbeitet und darum die Aufteilung des Logs auf mehrere Dateien kaum noch spüren lässt. Grundsätzlich ist das hier in dieser Fallstudie aufgezeigte Verfahren praktikabel: ■

■

■

Zuerst werden die Gesamtstatistiken herangezogen, um einen Überblick zu erhalten, ob überhaupt Fehler aufgetreten sind. Hierzu werden benötigt: Die Name Service-Auswertung von HostMagic sowie die TCP/IP- und Layer-7Ergebnisse aus SpiderMagic (das ist das Pflichtprogramm; es können selbstverständlich auch die anderen Funktionen zusätzlich genutzt werden). Sodann geht man den Hinweisen nach, die sich auf diese Weise ergeben. Dies geschieht durch Arbeit am Event-Log, unterstützt durch das EventFilter-Modul. Zur Verifikation und zur Abrundung des Gesamtverständnisses werden einzelne Fundstellen schließlich in den Original-Traces herangezogen. Da im Event-Log für jedes Ereignis die Nummer der Trace-Datei sowie die Nummer des LAN-Pakets angegeben werden, ist es völlig simpel, selbst bei 30 GB Messdaten und 100 Millonen LAN-Paketen in Sekundenschnelle die anvisierte Fundstelle zu öffnen und zu untersuchen.

Insofern dient das Event-Log auch als Index bzw. Inhaltsverzeichnis über Gigatonnen von Messdaten – was eine Übersicht ermöglicht, die uns die etablierten Hersteller bis heute schuldig geblieben sind: Sie geben uns zwar die Technik, die Messdaten auf die Festplatte zu schreiben, aber sie geben uns keine Chance, in den Messdaten schnell und zielgenau zu navigieren. (Ausnahme: NetVCR von Niksun; aber die von NetVCR zur Verfügung gestellten Indizes beinhalten nur einfache Verkehrsstatistiken und keine Analyse bzw. Fehlerhinweise.) Was aber nutzen 10 oder 50 Gigabyte Messdaten, wenn man darüber nicht schnell und sicher navigieren kann? Die Arbeit am Event-Log führt also am Ende häufig zum Aufruf der originalen Trace-Dateien, um die eigentlichen Fundstellen im Zusammenhang zu sichten und zu bewerten. Niemand ist gezwungen, sich nur den automatisch erzeugten Reports von TraceMagic auszuliefern. Die Möglichkeit, schnell und unkompliziert eine eigene Verifikation vorzunehmen, ist wichtig für das Vertrauen ins

>>> NEW TECH

571

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Werkzeug – und für den Kunden wichtig für das Vertrauen zum Dienstleister, der dieses Werkzeug benutzt. Alles dies wird in den folgenden Abschnitten zu sehen sein.

14.4.1 Event-Filter auf NiAgnt32.exe Es war bereits in den TraceStatistics (Tabelle 5: SMB/Denied Resources) aufgefallen, dass die Datei NiAgnt32.exe in bizarr anmutenden Mutationen gesucht wird. Es ist also zu fragen: Wer tut denn solches?

Abbildung 14.76: Event-Log: Fehlzugriff von Client IP = 192.168.2.195 auf \NiAgnt32.exe.Manifest und \NiAgnt32.exe.Local

Der einfachste Weg ist es, im Event-Log mit der Suchfunktion des Texteditors die Fundstelle aufzusuchen (siehe Abbildung 14.76). Aber, wie oben bereits beschrieben: Falls mehrere Event-Log-Dateien vorliegen, ergibt das keinen Sinn mehr und selbst bei nur einer einzigen Event-Log-Datei hätte man gerne eine schnelle Übersicht statt verteilter Fundstellen. Also wird das EventFilter-Modul aufgerufen und genutzt, um einen Filter auf das folgende Textmerkmal zu setzen: NiAgnt32.exe

Um das Beispiel etwas auszuweiten, wird der Textfilter mit zwei Vorgaben gestartet, nämlich mit NiAgnt32.exe.Local und NiAgnt32.exe.Manifest, wobei eine ODER-Verknüpfung dafür sorgt, dass jede Fundstelle für sich und einzeln ausreicht, um eine Log-Zeile als Treffer zu werten und in das neue Sub-Log zu übernehmen. Werden Fundstellen getroffen, wird eine neue Sub-Log-Datei erzeugt, welche alle Fundstellen enthält. Im aktuellen Beispiel liest sich das wie folgt: [ 1] (I) /# 2013 :: 22.16.8.24 >> NEW TECH

TraceMagic/Event-Log und EventFilter

Abbildung 14.77: Event-Log/Event-Filter: Je Filterkriterium (einzeln oder kombiniert) wird jeweils eine neue Sub-Log-Datei erzeugt. Hier sind die Eingabefelder 3 und 4 mit den Filtervorgaben NiAgnt32.exe.Local und NiAgnt32.exe.Manifest belegt. Durchsucht werden die in der Datei-Liste rechts aufgeführten Event-Log-Dateien (hier nur eine einzige). Event-Log

Bedeutung

[

Erste Trace-Datei

1]

(I) #2013 /#2013 \#2014

Siehe Trace-Index am Kopf der ersten Event-Log-Datei LAN-Paket Nummer 2013 (in Trace-Datei Nummer 1) Die LAN-Pakete Nummer 2013 und 2014 bilden gemeinschaftlich ein geschlossenes Ereignis, etwa Erst- und Zweitübertragung bei einer TCP Retransmission, oder Client-Request und Server-Reply bei einem Datendialog. Die Schrägstriche stellen eine Klammer dar, welche die beiden Pakete (logisch) zusammenhalten. Nicht immer müssen die paarweise zusammengestellten LAN-Pakete unmittelbar aufeinander folgen (keine durchgehende Nummerierung also); sie können mehrere hundert Pakete auseinander liegen.

Tabelle 14.6: Event-Log: Die wichtigsten Orientierungsmerkmale zur Navigation über Trace-Fundstellen

Es bietet sich natürlich an, erst mit dem EventFilter-Modul zu arbeiten und sodann in die eigentlichen Event-Log-Dateien zurückzugehen, um dort die Ereignisabläufe im Ganzen zu betrachten (hier sind wir nun umgekehrt vorgegangen).

>>> NEW TECH

573

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.78: Event-Log/Event-Filter/Sub-Log (Ergebnis): Alle Vorkommnisse der gesuchten Textstellen NiAgnt32.exe.Local und NiAgnt32.exe.Manifest wurden aus dem Event-Log herausgezogen und in separater Sub-Log-Datei abgespeichert.

Das Beispiel lehrt uns: ■

■

■

Der Client mit der Adresse IP = 192.168.2.195 sucht nach Dateien, die es nicht gibt, da die Dateinamen durch Anhängen der Erweiterungen .Local und .Manifest mutiert wurden. Der Server mit der Adresse IP = 22.16.8.24 gibt keinen Zugriff auf diese Phantom-Dateien, wie an der Bewertung ACCESS_FAILURE (Fehlzugriff) sichtbar wird. Diese Bewertung wird von TraceMagic automatisch vorgenommen. Dieses Verhalten ist verboten und stellt einen üblen Fehler des Clients dar.

Es stellt sich die Frage: Ist dieser Fehler typisch für den Net-Installer? Tritt er nur mit dem Net-Installer auf (dann wäre es ein Applikationsfehler) oder tritt er auch in anderen Zusammenhängen auf? Diese Frage ist letztlich nur zu beantworten, wenn man die Daten vieler LANs auswertet. Aus Erfahrung kann wenigstens gesagt werden, dass ein sehr wahrscheinlich fester Zusammenhang zwischen dem Fehler und dem Net-Installer besteht, da dieses Verhalten häufig dort zu beobachten ist, wo der Net-Installer vorhanden ist. Tatsächlich ergeben sich weitere Hinweise, wenn das Client-Verhalten weiter untersucht wird – denn dann stößt man auf das Batch-File NI5_FH.BAT und verschiedene Versuche des Clients, die darin enthaltenen Anweisungen abzuarbeiten (siehe unten, Abschnitt 14.4.7: »Zugriffe auf (und Abarbeiten von) NI5_FH.BAT und rc.files«).

14.4.2 GETDC-Befehle via Broadcast Der WinXP-Client versucht bereits kurz nach dem Booten und nach Anmeldung am WINS-Server, (s)einen Primary Domain Controller (PDC) zu finden. Dies sollte normalerweise wie folgt geschehen: ■ ■

■

574

Vom DHCP-Server wird u.a. der Name der Domain bezogen (hier: CB_EDV). Nach Anmeldung am WINS-Server wird per WINS-Request zum Namen der Domain die zugehörige IP-Adresse abgefragt, worauf der WINS-Server die IP-Adresse des PDC zurückgibt. Der Client holt sich via ARP zur IP-Adresse des PDC dessen MAC-Adresse (Ethernet, Token-Ring, FDDI).

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

■ ■

Der Client schickt einen SMB-Mailslot mit GETDC-Befehl an den PDC, um diesen aufzufordern, sich in seiner Antwort als tatsächlicher PDC zu bestätigen. Sodann kann der Client per SMB-Mailslot mit NETLOGON-Befehl anmelden.

Im vorliegenden Fall jedoch schickt der WinXP-Client die SMB-Mailslots mit dem GETDC-Kommando nicht an die IP-Adresse des PDC, sondern an die lokale IP-Subnetz-Broadcast-Adresse. Diese GETDC-Broadcasts werden fortlaufend wiederholt – über den ganzen Trace hinweg. Es liegt also ein ständiges Abweichen von der Norm vor.

Abbildung 14.79: Event-Log: Der Client IP = 192.168.2.195 sucht mehrfach (wie sich zeigt: ständig) per GETDC-Broadcast nach (s)einem PDC – das ist so nicht vorgesehen.

>>> NEW TECH

575

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Es zeigt sich am Beispiel von Abbildung 14.79, dass dasselbe LAN-Paket im Event-Log mehrfach vorkommen kann, hier beispielsweise an der markierten Stelle das LAN-Paket mit der Nummer 14. Das ist für TraceMagic normal, wenn bzw. insofern mehrere, verschiedene Aussagen zu demselben LAN-Paket zu machen sind. Hierdurch erfahren wir: ■

■ ■

Der Client hat den NetBIOS-Namen METARISC-D36N13 und er adressiert seine Pakete auf NetBIOS-Ebene an einen Empfänger namens CB_EDV; da der Empfänger die NetBIOS-Ressourcen-Kennung trägt für PDC bzw. Domain, ergibt sich daraus, dass die NetBIOS-Pakete an den Primary Domain Controller gerichtet sind. Es handelt sich um IP-Broadcasts/Multicasts, die über den UDP-Port 138 arbeiten (das ist der Port für NetBIOS Datagram). Die SMB-Pakete enthalten so genannte MAILSLOT-Nachrichten mit dem NETLOGON-Kommando, kombiniert mit dem GETDC-Kommando, welches PDCs auffordert, sich zu erkennen zu geben bzw. zu bestätigen (das ist ein Sicherheitsmerkmal des Anmeldevorgangs).

TraceMagic unterscheidet sehr genau, ob die sensiblen GETDC-Kommandos als Unicast adressiert sind (und damit direkt an einen PDC adressiert sind) oder ob sie als Broadcast/Multicast und somit auf Verdacht in das Netzwerk hinein geschickt werden. Entsprechend wird in der Log-Zeile, welche das SMB-Ereignis ausweist, schon der Eintrag vorgenommen SMB: MAC Bcst/Mcst oder SMB: MAC Unicast. Diese Unterscheidung ist von äußerster Bedeutung zur Bewertung des hier sichtbaren Versuchs des Clients, (s)einen PDC zu finden. Es darf vermutet werden: Dieser Client hat ernste Probleme, sein Domänen-Logon durchzuführen. Nicht umsonst hat sich der Anwender beschwert!

14.4.3 Client ruft TCP-SYN auf Port 445, Server gibt TCP-RST zurück; SMB-IPC-Zugriff über Port 139 Wenig später versucht der WinXP-Client, den Server IP = 22.64.4.2 auf Port 445 über das TCP-SYN-Signal zum Aufbau einer Session zu bewegen. Der Server jedoch unterstützt den Port 445 nicht und gibt zum Zeichen der Ablehnung das TCP-RST-Signal zurück (siehe Abbildung 14.80). Eine vollständig über TCP-Port 445 laufende SMB-Kommunikation ist übrigens weiter unten in Abbildung 14.103 zu sehen – allerdings im Dialog mit einem anderen Server (nicht diesem). Um dies zu verstehen, muss die Besonderheit von TCP-Port 445 verstanden werden: ■

■

576

Bis einschließlich Windows NT 4 wurde das Client/Server-Protokoll der Windows-Welt, SMB (Server Message Block) über den TCP-Port 139 bewegt (NetBIOS Session). Ab Windows 2000 bzw. Windows XP kann SMB zusätzlich über den TCPPort 445 gesendet werden.

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

Abbildung 14.80: Event-Log: Die Versuche des Clients, den Server IP = 22.64.4.2 via Port 445 anzusprechen, werden mit TCP-RST abgewehrt bzw. abgelehnt. ■ ■

Der Port 445 wird gerne als Direct Host-Port bezeichnet, u.a. für Peer-toPeer-Kontakte zwischen Windows-Rechnern. Ursprünglich war der Port 445 einmal für Microsoft Directory Services vorgesehen. Wie das weitergeht, bleibt abzuwarten. Heute verwendet ihn Microsoft für SMB.

Die folgende SMB-Sitzung wird folglich nicht über den TCP-Port 445 etabliert, sondern über den alten TCP-Port 139. Sodann initialisiert der Client einen Zugriff auf das folgende Server-Share: \\WN-KT-SDC\IPC$

Hierbei handelt es sich nicht um ein Share im Sinne eines Ortes auf der Festplatte des Servers, sondern um einen logischen Prozess (IPC = Inter Process Communication). Abbildung 14.81 zeigt den SMB-IPC-Zugriff des Clients über den TCP-Port 139; in den Paketen 78 bis 82 findet der misslungene und per TCP-RST abgewehrte Versuch des Clients statt, parallel auf Port 445 eine Sitzung aufzubauen. Es handelt sich also um ein Problem der Abwärts-Kompatibilität innerhalb einer Migrations-Situation: Der WinXP-Client kann schon noch via TCP-Port 139 arbeiten, aber er möchte ganz gerne über TCP-Port 445 arbeiten (ersatzweise oder zusätzlich). Hier zeigt sich, was die praktische Seite der Handhabung anbetrifft, dass es ganz einfach ist, aus dem Text des Event-Logs heraus zu den originalen Fundstellen in den Trace-Dateien zu wechseln, wenn man nur erst einmal weiß, wo sich welches Ereignis versteckt. Ohne das Event-Log wäre das Aufspüren der entscheidenden Fundstellen innerhalb von Gigabytes an Messdaten völlig unmöglich.

>>> NEW TECH

577

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.81: Der SMB-IPC-Zugriff des Clients über den TCP-Port 139

14.4.4 Mehrfaches Lesen von 1.024 Bytes am selben Offset = 0 von LSARPC und SAMR Der WinXP-Client greift in der Folge auf die logische Ressource LSARPC zu (Local Security Authority/Remote Procedure Call) und wiederholt dabei mehrfach den identischen Lesezugriff: Der Server wird aufgefordert, an Datei-Position Null bzw. ab Offset = 0 die Datenmenge von 1.024 Bytes auszulesen und an den Client zu schicken. Dies ist ein auffälliges Verhalten, denn der Client hat nach dem Erhalt der Daten nach dem ersten Zugriff alles, was er wünscht, er müsste nicht erneut dieselben Daten anfordern. Neben dem mehrfachen Lesen von Daten am selben Offset von LSARPC findet ein Mehrfachzugriff auf den SAMR-Prozess statt (Security Account Manager). Dies ist auffällig (siehe Abbildung 14.85), wird doch auch hier ständig dieselbe Datenmenge am selben Offset gelesen. Der Unterschied zu den LSARPC-Zugriffen ist hier jedoch, dass die Datei nicht während der Wiederholungen geöffnet bleibt. Hier wird SAMR ständig neu geöffnet, gelesen und geschlossen. Einen sonderlichen Eindruck von Effizienz macht das nicht.

578

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

Zum Vergleich: Etwas später wird ein ähnliches Verhalten bei der Batch-Datei NI5_FH.BAT sichtbar werden; bei Dateien des Typs .BAT und .CMD jedoch erklären sich Mehrfachzugriffe an sich überlagernden Offsets anders (siehe unten, Abschnitt 14.4.7). An diesem Beispiel wird die Technik der Darstellung deutlich, mit der TraceMagic arbeitet. Als Beispiel wird das LAN-Paket Nummer 126 betrachtet: ■ ■

■

■ ■ ■

Paket 126 taucht zunächst einzeln auf mit der Beschreibung des LeseBefehls des Clients. Paket 126 taucht danach paarweise mit Paket 132 auf, welches die ServerAntwort enthält: Beide Pakete bilden (isoliert für sich betrachtet) einen Client/Server-Dialog und insofern gehören sie zusammen. Das Paket 132 wird außerhalb der sonstigen Paketreihenfolge an dieser Stelle vorgezogen (die Pakete 127-131 werden für den Moment übersprungen), um die paarweise Darstellung überhaupt erst zu ermöglichen. Die Pakete 127-131 sind selbstverständlich nicht vergessen, sie werden ganz normal danach weiter abgearbeitet. Pakete, die im Event-Log nicht vorkommen, sind unerheblich bzw. weisen keine Besonderheiten im Sinne der aktuellen Analyse auf. Die neben der paarweisen Darstellung der Pakete 126 und 132 zusätzlich noch einzelne Darstellung von Paket 126 erklärt sich wie folgt: Je nach der Funktionsauswahl im SpiderMagic-Menü (siehe oben) erfolgen auch die Einträge im Event-Log. In diesem Falle waren zwei verschiedene Funktionen aktiviert: (A) Alle Lesezugriffe von Clients sollten im Event-Log erscheinen. (B) Alle Auffälligkeiten in den Dialogen zwischen Client und Server sollten ausgegeben werden, so beispielsweise Lesezugriffe an Offsets, die schon zuvor bedient worden waren.

Wer im Laufe der Zeit die Textausgabe des Event-Logs besser kennen gelernt hat, kann über die Funktionsauswahl im SpiderMagic-Menü mehr den eigenen Wünschen entgegen kommen. Die Erfahrung aber zeigt, dass man alle Einstellungen in der Regel so lässt, wie sie sind, weil sich auf diese Weise das Maximum an Befunden herausholen lässt. Es finden sich, wie die Abbildungen zeigen, zudem die Angaben der File-Handles, also der vom Server bei der Zugriffsinitialisierung herausgegebenen Zugriffsschlüssel. Dies ist wichtig, da alle Client-Zugriffe auf Server-Ressourcen unter Nennung von (a) Zugriffsanzahl, (b) Erfolg, (c) File-Handle, (d) Ressourcen-Name in den folgenden Log-Dateien (Tabellen) abgelegt bzw. nachgewiesen werden (siehe Abbildung 14.95 und Abbildung 14.96): TM.SM.SpiderMagic.TABLES.~~NCP~~.File.Handles.(Open.Close).TXT TM.SM.SpiderMagic.TABLES.~~SMB~~.File.Handles.(Open.Close).TXT

Mittels dieser Tabellen kann jederzeit nachvollzogen werden, welches FileHandle zu welcher Datei gehört. Das ist extrem wichtig, wenn Lesevorgänge Fehler aufweisen, der Zeitpunkt des Öffnens der Datei jedoch ein paar tausend >>> NEW TECH

579

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Pakete oder ein paar Dutzend Trace-Dateien zurückliegt. Es wäre völlig unzumutbar für den Bearbeiter, den Client/Server-Dialog eines Dateizugriffs manuell so weit zurückzuverfolgen, bis ganz am Anfang beim OpenFile()-Befehl der Klarname der Datei bzw. der Ressource sichtbar würde. In solchen Fällen sieht man einfach in den FileHandles/OpenClose-Tabellen nach und ordnet dem FileHandle den Dateinamen im Klartext zu. Auch dies ist übrigens eine Funktion, die in der Analyse der Client/Server-Dialoge von äußerster Wichtigkeit ist, die aber von den etablierten Herstellern bis heute nicht entwickelt wurde. Man fragt sich wirklich, ob den Programmierern statt des Monatslohns Schlaftabletten verabreicht werden. Als ob Dateizugriffe völlig unerheblich wären! Zuletzt noch der Hinweis auf die Hinweistexte Current Frame bzw. Related Frame jeweils ganz rechts am Ende einer Event-Log-Zeile:

Abbildung 14.82: Event-Log: Zusammenhang paarweise auftretender Frames

Die mit dem Sternchen (*) gekennzeichnete Zeile markiert den aktuellen LANFrame, bei dem TraceMagic gerade in der Analyse angekommen ist. Gibt es einen Anlass, von dieser Stelle aus in den Messdaten rückwärts zu laufen und einen Bezug herzustellen zu einem der vorigen Frames, so tut dies TraceMagic und kennzeichnet den vorigen Frame als Related Frame. Gibt es einen Anlass, von der aktuellen Stelle vorwärts zu laufen und einen Bezug zu einem der später folgenden Frames herzustellen, so tut dies TraceMagic und kennzeichnet den folgenden Frame als Related Frame. Ein Anlass, in den Messdaten rückwärts zu laufen, ist beispielsweise die Rückgabe eines Error-Codes durch einen Server an einen Client: Dann läuft TraceMagic zurück, um den zum Server-Reply gehörenden Client-Request zu suchen. Ähnlich verhält es sich bei TCP Retransmissions. Ein Anlass, in den Messdaten vorwärts zu laufen, ist beispielsweise der ClientBefehl an einen Server, eine Datei zu öffnen: Dann läuft TraceMagic vorwärts bis zur Server-Antwort, um zu sehen, ob der Server den Zugriff genehmigt bzw. welches File-Handle der Server zurückgibt. Dieses Vorwärts- und Rückwärtslaufen außerhalb des normalen Verarbeitungsfortschritts wird im TraceAnalysis-Fenster mit kleinen gelben (Rücklauf) und grünen (Vorlauf) Pfeilen dargestellt, die jedes Mal eingeblendet werden, wenn ein solcher Vorgang eintritt. An solchen Funktionen zeigt sich übrigens, dass Online-Analyzer (zwar unverzichtbar sind, aber) diese Form der Untersuchung nicht leisten können, weil sie Zeit braucht und Ressourcen bindet – was beides während der laufenden Messung nicht hinreichend zur Verfügung steht. 580

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

Das ist kein Vorwurf an die Online-Analyzer: Es ist schlicht eine Feststellung, die dazu führt, dass man Online-Analyse und Offline-Analyse in ihrem Leistungsspektrum deutlich voneinander absetzen muss. Es sind eben zwei völlig verschiedene Teilschritte auf dem langen Weg zu einer gültigen Diagnose des Netzwerk-Verkehrs.

Abbildung 14.83: Event-Log: Mehrfache Lesezugriffe des Clients am selben Offset von \LSARPC (1)

>>> NEW TECH

581

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.84: Event-Log: Mehrfache Lesezugriffe des Clients am selben Offset von \LSARPC (2)

582

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

Abbildung 14.85: Event-Log: Mehrfaches Öffnen/Lesen(Schließen mit Bezug auf den SAM (Security Account Manager) des Servers

>>> NEW TECH

583

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

14.4.5 Mehrfache Wiederholungen derselben sinnlosen DNS-Anfragen Der WinXP-Client zeigt noch andere auffällige Verhaltensweisen. Dieses Mal geht es um seine Art, mit Namens- und Adressauflösungen umzugehen. Die folgenden Beispiele zeigen, dass mehrfach nach DNS-Namen gesucht wird, die keinen FQN (Fully Qualified [DNS] Name) darstellen, da ihnen das lokale Domain-Suffix fehlt. Solche DNS-Requests sind nicht unbedingt verboten, aber solange sinnlos, wie der DNS-Server nicht kompatibel eingestellt ist. D.h. es können durchaus DNSServer so konfiguriert werden, dass sie auch Anfragen nach einfachen HostNamen erfolgreich auflösen, indem sie selber das Anhängen der lokalen Domain-Suffixe besorgen und entsprechend den Abgleich mit ihren Tabellen durchführen. Da diese DNS-Server-Einstellung aber die absolute Ausnahme ist, verfährt Microsoft i.d.R. so, dass die DNS-Clients selber bei einem Auflösungsfehlversuch das lokale Domain-Suffix anhängen. Genau das geschieht hier aber entweder gar nicht (siehe Abbildung 14.86) oder erst im letzten Versuch (siehe Abbildung 14.87). Beides ist nicht erwünscht – und beides sorgt wegen der vielen, völlig sinnlosen Wiederholungen der DNS-Requests zu Wartezeiten, die sich jedes Mal wieder aufsummieren, bis der Anwender sagt: »Das Netzwerk ist langsam.« Die Beispiele in Abbildung 14.87 und Abbildung 14.88 zeigen zudem die tiefe Fragwürdigkeit des Vorgehens, da die jeweils rettende WINS-Auflösung erst nach den wiederholten DNS-Versuchen stattfindet. Der WinXP-Client ist darauf eingestellt, zunächst DNS als primären Namensdienst zu verwenden. Gut und schön, dagegen ist nichts einzuwenden. Dann aber soll er doch – bitte, schön! – bereits nach dem ersten DNS-Fehlversuch (oder nach nur wenigen Fehlversuchen) schnell zu WINS wechseln, anstatt sich dermaßen zu verbeißen. Hier ist offenkundig eine Desorientierung in der logischen Organisation der Adress- und Namensdienste vorhanden, die der Anwender in Form von Wartezeit zu bezahlen hat. Zur Erinnerung: Die ersten Hinweise auf Fehler dieser Art wurden schon sichtbar in den Ergebnistabellen von HostMagic (siehe Abbildung 14.15). Da wir uns an jener Stelle fest vorgenommen hatten, den dort schon auftretenden Hinweisen nachzugehen, haben wir diese Pflicht nun erledigt und nachgewiesen, dass der WinXP-Client tatsächlich einen Schaden hat. Unklar ist an dieser Stelle, wie sich das unerwünschte Verhalten beseitigen ließe. Hier muss der Verfasser (der Macken in den Windows-Namensdiensten wirklich gut kennt) ausnahmsweise mal passen, weil es sich um einen wirklich weit außerhalb des Üblichen stehenden Fehler handelt. Vermutlich wird man mal wieder die Microsoft-Knowledgebase konsultieren (was nur höchst ungewisse Aussicht auf Erfolg bietet) und man wird das nächste Service-Pack abwarten. Wie so oft.

584

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

Abbildung 14.86: Event-Log: Mehrfach erfolglose Wiederholung des DNS-Requests bzgl. des (echten? vermeintlichen?) DNS-Host-Namens XL-SQ-SDC

Abbildung 14.87: Event-Log: Mehrfach erfolglose Wiederholung des DNS-Requests bzgl. des (echten? vermeintlichen?) DNS-Host-Namens PDC. Erst danach kommt die rettende WINSAbfrage. >>> NEW TECH

585

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.88: Event-Log: Mehrfach erfolglose Wiederholung des DNS-Requests bzgl. des (echten? vermeintlichen?) DNS-Host-Namens VI-ED-NI02. Erst danach folgt die rettende WINSAnfrage.

14.4.6 Server-Share wird als verstümmelte Datei-Anfrage missbraucht In Abbildung 14.89 ist zu sehen, wie der Client in Frame 799 einen Zugriff auf das folgende Server-Share einleitet: \\VI-ED-NI02\IPC$

Die Notation als UNC (Univeral Naming Convention) kennzeichnet den ersten Teil als Server-Namen, den zweiten Teil als Share-Namen (was in diesem Falle keinen Ort auf der Festplatte bezeichnet, sondern einen logischen Prozess des Servers). Der Server bestätigt den Zugriff mit Frame 800; das im Event-Log ausgewiesene [N/A] besagt nur, dass der Server keine eigene Nachricht zurückgibt (was oft der Fall ist, aber nicht der Fall sein muss). Sodann leitet der Client mit Frame 801 formal einen Dateizugriff ein. Man unterscheide: ■

586

Die SMB-Codes 0x72 (Frame 793), 0x73 (Frame 796) und 0x75 (Frame 799) werden für Zugriffe verwendet, die mit dem Abgleich von Zugriffsberechtigungen zu tun haben bzw. die übergeordnete Zugriffe darstellen wie eben auf Shares. Zugriffe auf Shares finden statt unter Übergabe eines UNC wie \\NI-ED-NI02\IPC$. >>> NEW TECH

TraceMagic/Event-Log und EventFilter

■

Der SMB-Code 0x32 (Frame 801) wird für nachfolgende bzw. nachgeordnete Zugriffe auf Dateien und Ressourcen genutzt. Diese Zugriffe finden unter Übergabe eines Festplattenpfades statt (gerechnet ab dem logischen Hauptverzeichnis des Server-Shares).

Im vorliegenden Fall nun kommt der WinXP-Client auf die interessante Idee, einen der Form nach auf eine Datei gerichteten Zugriff (SMB-Code 0x32) mit einer der Form nach als Verzeichnispfad strukturierten Zeichenfolge durchzuführen: \VI-ED-NI02\NI5$. Dieses ist offenkundig unsinnig und grundfalsch. Bei VI-ED-NI02 handelt es sich um einen Server-Namen und nicht um ein Verzeichnis. Sicherlich: Niemand verbietet, auf dem Server verschiedene Unterverzeichnisse nach Server-Namen zu benennen. Aber erstens zeigt sich hier schon in der gesamten Zeichenfolge, dass es sich um einen kastrierten UNC handelt (einer der beiden Backslashes links vorne wurde weggenommen), und zweitens zeigt die Antwort des Servers, was er davon hält: nämlich gar nichts. Der Zugriffsversuch scheitert. Es dürfte kein Zufall sein, dass unmittelbar danach der Client die Initialisierung des Shares mit dem Befehl Tree Disconnect zurücknimmt. Das ganze Unternehmen war also nur ein peinliches Missverständnis, wenn man so will. Derart missliche Fehler aber sollten Microsoft im Jahre 2002 wirklich nicht mehr unterlaufen (siehe Abbildung 14.89).

14.4.7 Zugriffe auf (und Abarbeiten von) NI5_FH.BAT und rc.files Spannend wird es, wenn man die Zugriffe auf die Batch-Datei NI5_FH.BAT verfolgt sowie das Abarbeiten der in diesem Script hinterlegten Befehle. Die Batch-Datei NI5_FH.BAT ist im Zusammenhang mit dem Net-Installer zu sehen; jeder Client soll dieses Script beim Login abarbeiten und auf diese Weise ggf. Datei-Aktualisierungen erfahren. Zur Erinnerung: Die Einstellungen im SpiderMagic-Menü entscheiden darüber, ob bzw. welche Dateien aus Client/Server-Dialogen mit ihrem Inhalt rekonstruiert und auf die Festplatte geschrieben werden (siehe Abbildung 14.90) und zwar innerhalb des Projektverzeichnisses der aktuellen Analyse (siehe Abbildung 14.91) in das dortige rc.files-Unterverzeichnis (siehe Abbildung 14.92). Im aktuellen Fall wurden rund 30 Lesezugriffe in Dateiform rekonstruiert, wobei sich die meisten dieser Lesezugriffe auf die Batch-Datei NI5_FH.BAT richten. Der Umstand, dass so viele Rekonstruktionen derselben Batch-Datei anfallen, obwohl der Client dieses Script doch nur einmal abarbeitet, liegt darin begründet, dass der Client die Batch-Datei Zeile für Zeile ausliest bzw. abarbeitet. Für jede Zeile wird die Datei erneut geöffnet, gelesen und geschlossen.

>>> NEW TECH

587

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.89: Event-Log: Die Initialisierung eines Zugriffs auf das Share \\VI-ED-NI02\NI5$ erfolgt hier verstümmelt als \VI-ED-NI02\NI5$ in der Form eines Dateizugriffs – was einen massiven, logischen Fehler darstellt, da ein UNC-Name kein Festplattenpfad ist (vgl. Pakete 799 und 801).

588

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

Dieses Verfahren ist unter den Bedingungen jüngerer Windows-Versionen im Grunde völlig unsinnig – woher nun stammt es? Es ist ein Überbleibsel aus alten DOS-Tagen: Damals waren 640 KB RAM ein kostbares Gut und es war nicht ratsam, eine ganze Batch-Datei in den Hauptspeicher einzulesen und dort bis zum Ende der Verarbeitung liegen zu lassen. So wurde immer nur eine einzelne Zeile eingelesen und in den Zeilenspeicher gelegt. Das ist im Grunde bis heute so geblieben. Verändert hat sich, dass der Client (der ja heute über mehr RAM verfügt) stets große Datenmengen anfordert (etwa: 1.024 oder 4.096 Bytes), aus dieser Datenmenge dann jeweils die erste, vorne liegende Textzeile herausschält (das geht ganz einfach: alle Zeichen bis zum nächsten Carriage-Return And Line-Feed) und sodann den gesamten Rest verwirft – obwohl darin ein paar Dutzend weitere Zeilen enthalten sind oder sogar der gesamte Rest des Batch-Files. Aber das wäre zu einfach gewesen. So wird eben für jede Zeile die Datei neu geöffnet, gelesen und geschlossen, wobei der Start-Offset jedes Mal ein Stückchen weiter rückt (je nach erreichter Position). Es ist durchaus verständlich, dass Microsoft bewährten Programm-Code nicht einfach so und ohne Not über Bord wirft. Aber manchmal mutet eine über nun schon 20 Jahre währende Abwärts-Kompatibilität etwas eigenartig an. Wir wollen mal schauen, ob wir das im Jahre 2010 oder 2020 dann immer noch so machen.

Abbildung 14.90: TraceMagic/SpiderMagic/Einstellungen zu rc.files

>>> NEW TECH

589

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.91: Das rc.files-Verzeichnis innerhalb des Projektverzeichnisses des aktuellen AnalyseDurchgangs

Abbildung 14.92: Der Inhalt des aktuellen rc.files-Verzeichnisses

590

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

Abbildung 14.93: Das von TraceMagic aus den Messdaten wiederhergestellte Batch-File NI5_FH.BAT als reconstructed file im rc.files-Verzeichnis

Doch nun zur anstehenden Analyse dessen, was da geschieht – denn offensichtlich läuft nicht alles so, wie es soll. Der Anlass für Nachforschungen im Zusammenhang mit dieser Stapelverarbeitungs-Datei ergibt sich durch Hinweise im Event-Log, die auf das Batch-File NI5_FH.BAT weisen, wie wir gleich sehen werden. Doch zunächst soll der Hergang der Dinge chronologisch in den Blick genommen werden. Der Zugriff auf das Batch-File wird erstmals in Frame 1710 ff. vorbereitet: ■ ■ ■ ■

Frame 1710: Das NetWare-Verzeichnis \PUBLIC wird angesteuert. Frame 1713: Datei-Info zu \PUBLIC\NI5_FH.BAT wird abgefragt. Frame 1715: Der Client gibt Befehl zum Öffnen der Datei. Im weiteren Fortgang wird die Datei mehrfach geöffnet, gelesen und geschlossen.

Der NetWare-Server IP = 22.16.8.102 befolgt die Client-Befehle, die Datei zu öffnen, anstandslos. Was das angeht, läuft alles einwandfrei (siehe Abbildung 14.94). Alle Dateizugriffe sind in den für SMB und NCP separat geführten Zugriffstabellen nachlesbar, wobei es in diesen Tabellen wesentlich darum geht, Erfolg und Misserfolg auszuweisen – bei Misserfolg kennzeichnet dies ein Sternchen (*) – und dem Dateinamen das jeweils vom Server zugeordnete File-Handle auszuweisen (siehe oben, Abschnitt 14.4.4).

>>> NEW TECH

591

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.94: Event-Log: Die ersten Zugriffe des Clients auf NI5_FH.BAT

Abbildung 14.95: TraceMagic/SpiderMagic: Nachweis der File-Handles für Dateizugriffe via NCP

592

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

Abbildung 14.96: TraceMagic/SpiderMagic: Nachweis der File-Handles für Dateizugriffe via SMB

Abbildung 14.97: Event-Log: Einer der Zugriffe auf NI5_FH.BAT findet mit völlig verfälschter Pfadangabe statt – danach stimmt’s dann wieder.

Kommen wir zu den Fehlern, die mit FI5_FH.BAT in Verbindung stehen. Als Erstes springt ins Auge, dass der WinXP-Client offenkundig die Abwechslung liebt und die sterbenslangweilige Monotonie ewig gleich bleibender Verzeichnispfade durch gelegentliche Mutationen aufzulockern gedenkt. Im aktuellen Fall vergleiche man die beiden folgenden Pfade: ■ ■

Frame 1761: PUBLIC\VI-ED02\SYS\PUBLIC\NI5_FH.BAT Frame 1767: PUBLIC\NI5_FH.BAT

>>> NEW TECH

593

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Wer die interne Struktur von Netware-Servern kennt, wird sich ein Schmunzeln nicht versagen können, handelt es sich doch ... ... bei VI-ED02 um den Namen des Servers, ... bei SYS um den Namen des Festplatten-Volumes, ... bei PUBLIC um den Namen eines der System-Verzeichnisse auf SYS. Klar, dass es nicht sonderlich viel Sinn ergibt, das Verzeichnis PUBLIC gleich zweimal in die Pfadangabe zu schreiben, und ein verkorkster UNC wird auch dadurch nicht besser, dass man ihn durch einen vorangestellten Verzeichnisnamen (nämlich: PUBLIC) hübsch verziert. Es ist völlig unklar, was den WinXP-Client dazu bringt, diesen netten Einfall zur Ausführung zu bringen. Klar ist nur, dass er wenige Pakete später wieder alles so macht, wie es sich gehört, und das Batch-File kann weiter gelesen werden. Man muss Humor haben, keine Frage! Dieses Verhalten steht in gewisser Weise dem schon zuvor nachgewiesenen Fehler nahe, den der WinXP-Client einem Windows-Server gegenüber gezeigt hat, nämlich die Umwidmung eines UNCs zu einem Verzeichnispfad (siehe Abschnitt 14.4.6). Es zeigt sich also über die Protokolle NCP und SMB gemeinsam hinweg so etwas wie ein gleich bleibendes Handlungsmuster. Tatsächlich kann der Verfasser sagen, derlei Fehler praktisch in vielen, wenn nicht den meisten Netzwerken zu finden, deren Analyse ihm in den letzten Jahren anvertraut wurde. Es kann sich also nicht um Zufall handeln. Erschreckend ist, dass auch jüngere Windows-Versionen wie Windows 2000 oder Windows XP (immer noch) nicht frei sind von derlei Fehlern. Doch gehen wir weiter im Verlauf der Ereignisse, die ja noch nicht abgeschlossen sind. Wir hatten schon zuvor festgestellt, dass es auffällige Wiederholungen in DNSAnfragen gibt (siehe oben, Abschnitt 14.4.5). Diese DNS-Anfragen rücken nun in ein anderes Licht, wenn wir sie im Zusammenhang mit dem Batch-File NI5_FH.BAT betrachten, denn es zeigt sich, dass im Zuge des Client-Versuchs, die im Batch-File enthaltenen Anweisungen abzuarbeiten, diese DNS-Anfrage zu Stande kommt. Man vergleiche Abbildung 14.93 und den darin abgebildeten Inhalt von NI5_FH.BAT; die entscheidenden Zeilen sind: REM Installation des Agent von NetInstall 5.x \\VI-ED-ni01\ni5$\niagnt32.exe /install

Der Client ist also zwangsweise gehalten, zum Zugriff auf die Datei zunächst den UNC aufzulösen, denn korrespondierend zum Server-Namen VI-ED-NI01 wird die IP-Adresse benötigt. Dies führt zu DNS-Anfragen, bei denen jedoch nur der Host-Name VI-ED-NI01 übergeben wird, nicht aber ein vollständiger DNS-Name unter Einschluss des lokalen Domain-Suffixes. Erst nach mehreren Wiederholungen der gleich bleibend erfolglosen DNS-Versuche bringt dann ein WINS-Request Erlösung (siehe Abbildung 14.98).

594

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

Der Client hat dann die Aufgabe, den Zugriff auf das Share \\VI-ED-NI01\NI5$ einzuleiten – was eine heikle Aufgabe wäre, sofern der Server kein WindowsServer wäre, sondern ein NetWare-Server, bei dem die bei Microsoft übliche Kennzeichnung eines Shares über das Dollar-Zeichen auf wenig Beliebtheit stieße. Der Client muss also die Textzeile in dem Batch-File so umsetzen, dass sie für den Zugriff auf den NetWare-Server tauglich ist. Es wird daraus ersichtlich, dass in einer heterogenen Server-Landschaft selbst in so kleinen Details wie einer simplen Script-Zeile der Teufel im Detail stecken kann. Für die Umsetzung der Namens- und Adressauflösungen bzw. der korrekten Einleitung der Ressourcen-Zugriffe ist der folgende Windows-Treiber zuständig: MUP.SYS = Multiple UNC Provider

Dieser Treiber muss zum Teil wahre Wunder vollbringen, wenn auf dem Windows-Client alle nur denkbaren Protokoll-Stapel geladen sind und die Zugriffe immer einwandfrei ablaufen sollen. Sollte MUP.SYS bei seiner Arbeit ein Fehler unterlaufen bzw. sollten verschiedene Treiber-Stapel bzw. Server-Landschaften verwechselt werden, kommt es zu Fehlern etwa der Art, wie sie in dieser Fallstudie dokumentiert sind. Jedoch – Vorsicht! Fehler dieser Art können, aber müssen nicht auf MUP.SYS zurückzuführen sein! Es können auch Ereignisse bzw. Anweisungen der Applikationen sein, die dazu führen, oder aber Netzwerk-Treiber Dritter, also etwa der NetWare 32-Bit Client Requester von Novell. Um hier die nötigen Abgrenzungen vorzunehmen, bleibt ggf. nichts anderes übrig, als das folgende Vorgehen zu entfalten: ■ ■ ■ ■ ■ ■

■

Nackten Client aufsetzen, nur die Microsoft-Treiber aktivieren. Rechner anfahren und mit LAN-Analyer sehen, wie er sich verhält. Jetzt nach und nach Fremdtreiber und Applikationen schichtweise installieren Rechner jedes Mal wieder anfahren und mittels LAN-Analyer kontrollieren Bei einem dieser Schritte wird dann erstmals das Fehlverhalten sichtbar werden. Aber Achtung! Es muss nicht unbedingt das letzte installierte Stück Software sein, welches das Fehlverhalten verursacht. Klar ist bis dahin nur, dass es einen Einfluss gibt, vermutlich in Form einer Treiberunverträglichkeit. Also müssen die Tests ein paar Mal von Anfang an wiederholt werden, wobei die Reihenfolge der Software-Installationen geändert wird. Im schlechtesten Fall ist erst nach Durchlaufen aller Varianten klar, welche Ursachen und Wechselwirkungen da gegeben sind.

Das hört sich schlimmer an, als es ist, und führt in den meisten Fällen mit annehmbarem Aufwand zum Ergebnis.

>>> NEW TECH

595

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.98: Event-Log: Erst in steter Wiederholung erfolglose DNS-Requests, dann – erst spät – der erlösende WINS-Request bzgl. VI-ED-NI01

596

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

Abbildung 14.99: Event-Log: Das Öffnen von niagnt32.exe in den Frames 1994, 1996, 2000 etc. wird jeweils zurückgeführt auf das vorherige Einlesen von PUBLIC\ni5_FH.BAT in (bzw. ab) Frame 1917 (dokumentiert in den rc.files).

>>> NEW TECH

597

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.100: Event-Log: Die Log-Zeilen enthalten explizit den Hinweis darauf, dass die Zugriffe auf \niagnt32.exe sehr wahrscheinlich zurückzuführen sind auf einen Script-Command, der sodann als Client Request ausgeführt wird, nachzulesen im rekonstruierten Inhalt der Datei ni5_fh.bat, von TraceMagic abgelegt im rc.files-Verzeichnis.

Bei jedem Befehl, eine Datei auf einem Server zu öffnen, prüft TraceMagic bzw. SpiderMagic nach, ob sich dieser Vorgang auf einen Script-Befehl zurückführen lässt. Dies geschieht dadurch, dass alle Scripts, die der Client von einem der Server zuvor eingelesen hat, Anweisungen enthalten, welche diese Datei betreffen. Voraussetzung hierfür ist jedoch, dass vor Start der SpiderMagic-Analyse die entsprechenden Einstellungen getroffen wurden (siehe Abbildung 14.90). In diesem Falle ist es so, ■ ■

dass das Batch-File NI5_FH.BAT von einem NetWare-Server gelesen wurde, dass die Auffälligkeiten und Fehler sich dann aber gegenüber einem Windows-Server ereignen.

Das ist nicht weiter auffällig, soll aber zeigen, dass TraceMagic nicht auf die einzelnen Protokolle NCP bzw. SMB eingeschränkt arbeitet, sondern übergreifend diese Tests vornimmt. Im vorliegenden Falle unseres Windows XP-Clients erleben wir also, dass die Versuche, der Datei NiAgnt32.exe habhaft zu werden (ausgelöst durch einen Script-Befehl NI5_FH.BAT), zu Fehlbildungen im Dateinamen führen. Die folgenden zwei Mutationen werden beobachtet: ■ ■

NiAgnt32.exe.Local NiAgnt32.exe.Manifest

Die Mutation von Dateinamen ist bei Windows-Clients immer wieder mal zu beobachten, wobei die hier sichtbaren Beispiele noch eher harmlos sind. Wie man schnell und einfach alle Fehler eines bestimmten Mutations-Typs nachweist, wurde bereits weiter oben beschrieben (siehe Abschnitt 14.4.1: »Event-Filter auf NiAgnt32.exe«).

598

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

Ansonsten ist zur schnellen Erkennung solcher Fehler die Tabelle 5 (SMB/Denied Resources) in den TraceStatistics unverzichtbar, weil sie alle Vorkommnisse dieser Art mit einem einzigen Mausklick sichtbar macht – indem man schlicht die Datei-Endungen der von allen Clients angeforderten Dateinamen sortiert (siehe oben, Abschnitt »Tabelle 5: SMB Client Resource Requests/Server Error Returns«). Zum Abschluss der Betrachtungen zur Batch-Datei NI5_FH.BAT soll anhand zweier Quellen in den TraceMagic-Report-Dateien gezeigt werden, dass bzw. wie oft Stapelverarbeitungs-Dateien des Typs .BAT oder .CMD geöffnet, gelesen und geschlossen werden.

Abbildung 14.101: TraceMagic/SpiderMagic: Nachweis aller Dateizugriffe samt des vom Server ausgegebenen File-Handles. Hier zu sehen: Das stete Öffnen und Schließen in Serie, wenn es um Batch-Files geht

>>> NEW TECH

599

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.102: Event-Log: Eine Stelle im Ablauf, bei welcher der WinXP-Client das Batch-File NI5_FH.BAT gut sichtbar für nur jeweils einen einzigen Lesezugriff öffnet. Für jede Zeile fällt ein separater Zugriff an.

14.4.8 Zugriff auf die Datei NiApMgnt.dll – verzögert durch TCP-ReTx Das folgende Ereignis zeigt zweierlei (siehe Abbildung 14.103): ■

■

dass das Laden der Datei NiApMgnt.dll erheblich gestört wird, wie die TCP Retransmissions zeigen – vermutlich auf Grund von Paketverlusten im LAN, dass die Analyse Wechselwirkungen auf der Applikationsebene und der TCP/IP-Ebene möglichst gut sichtbar bzw. nachvollziehbar machen muss.

Haben wir es bisher allein mit Vorgängen der Name Services (DNS, WINS) und File Services (NCP, SMB) zu tun gehabt, so wird der geplagte WinXP-Client nun auch noch von Paketverlusten heimgesucht, die sich unübersehbar in TCP Retransmissions (TCP ReTx) auswirken. Bei näherer Betrachtung des Event-Logs (das in der dafür erforderlichen Länge hier nicht abgebildet ist) stellt man fest: Dieses Verhalten setzt plötzlich ein, dauert eine Weile und dann ist es wieder verschwunden. Es ist also gut möglich, dass eine sponane Überlast irgendwo dieses Verhalten hervorruft.

600

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

Abbildung 14.103: Event-Log: Beim Auslesen von \NiApMgnt.dll treten plötzlich massiv TCP Retransmissions (TCP ReTx) auf – vermutlich auf Grund von Paketverlusten.

14.4.9 Verdacht: IP-Pakete treten in verdrehter Reihenfolge auf Wir hatten schon zuvor bei Durchsicht der TraceStatistics/Tabelle 1 (TCP/IPGesamtstatistik) festgestellt, dass die Nummerierung der IP Packet ID den starken Verdacht rechtfertigt, die IP-Pakete könnten auf dem Wege vom Absender bis zum Messpunkt in ihrer Reihenfolge verdreht worden sein (siehe Abschnitt 14.3.5: »Tabelle 1: Analysis Summary (IP-ICMP-TCP)« und »Tabelle 4: IP Host Events/Errors/Statistics«). Ein solches Ereignis kann unter folgenden Bedingungen auftreten: ■

■

■

Die IP-Pakete durchlaufen vom Absender bis zum Empfänger unterschiedliche Wege. Dies muss als Hinweis gewertet werden entweder (a) auf Instabilitäten in der WAN-Wolke oder (b) auf falsche Einstellungen im Load Balancing in der WAN-Wolke. Die IP-Pakete werden in den Buffer-Queues eines Switches oder Routers nicht nach dem FIFO-Prinzip behandelt (FIFO: First-In, First-Out), sondern nach anderen Kriterien – was innerhalb einer Ende-zu-Ende-Beziehung nicht sein darf (Ende-zu-Ende: von Endgerät zu Endgerät sowie daselbst von Applikations-Instanz zu Applikations-Instanz). Im Campus-LAN ist das Load-Balancing zweifelhaft organisiert: Normalerweise soll der Lastausgleich zwischen verschiedenen, physikalischen Wegen auf einer per-session-basis organisiert werden, nicht auf einer per-packetbasis.

>>> NEW TECH

601

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

■

■

Üblich ist, dass Switches und Router mit so genannten Pfadabbildungen arbeiten, bei denen für eine Ende-zu-Ende-Beziehung ein Tabelleneintrag angelegt wird, der neben Eingangs-Port und Ausgangs-Port, IP-Subnetz etc. auch ggf. weitere Kriterien wie Priorität, VLAN-Zugehörigkeit etc. abbildet. Ist dieser Tabelleneintrag einmal vorgenommen, bedeutet ein Load Balancing auf per-session-basis, dass auch alle weiteren IP-Pakete, die dieser Sitzung zugehören, nach den Bedingungen dieses Tabelleneintrags weitergeleitet werden – und somit immer denselben Weg nehmen. Ein Load Balancing auf per-packet-basis arbeitet so, dass für jedes IP-Paket die Entscheidung wieder neu getroffen werden muss. Dies versucht man strikt zu vermeiden und das aus guten Gründen: Erstens würde der Switch oder Router viel zu sehr belastet, wenn er jedes Mal wieder neu rechnen und entscheiden müsste. Zweitens würden (sofern im Laufe der Zeit alle Wege, die verfügbar sind, auch genutzt werden) auch sämtliche anderen Switches/Router gezwungen, für die gegebene Ende-zu-Ende-Sitzung zweiter IP-Hosts die entsprechenden Tabelleneinträge vorzunehmen – was eine sinnlose Verschwendung von Ressourcen wäre. Wird dagegen auf per-session-basis immer derselbe Weg genommen, ist auch die Zahl der Switches/Router begrenzt, welche die entsprechenden Pfadeinträge in den Tabellen vorzunehmen hätten. Ethernet: Möglich ist allerdings auch, dass Instabilitäten im LAN zu Topologie-Wechseln führen. In diesem Zusammenhang wäre auf Spanning-TreeAktivitäten zu achten, was messtechnisch bedeutet, dass die BPDUs (Bridge Protocol Data Units = Spanning-Tree-Pakete) gezielt auszuwerten sind (TraceMagic verfügt im Modul SpiderMagic über diese Fähigkeit). Token-Ring: Die bei Token-Ring übliche Vermaschung der verschiedenen Ringe aus Gründen der Redundanz bzw. Ausfallsicherheit kann unter sehr begrenzten Bedingungen dazu führen, dass Pakete über verschiedene Wege laufen und sich gegenseitig überholen; dies ist jedoch innerhalb derselben Dialogsitzung eher unwahrscheinlich.

Im vorliegenden Fall war zunächst nicht klar, welches Szenario vorliegt, weil keine weiteren Messdaten zur Verfügung stehen. Also war in den OriginalTrace hineinzusehen. Was zeigt sich da? Eine neue, hübsche Microsoft-Macke – was voraussetzt, dass es bereits eine alte, hübsche Microsoft-Macke gab: ■

602

Windows bis einschließlich Windows NT 4: Der 16-Bit-Zähler (DoppelByte, in der Programmiersprache WORD genannt) des IP-Paketzählers wird nur als 8-Bit-Zähler bedient und da nur das so genannte Hi-Byte (das höherwertige der zwei Bytes) hochgezählt wird, erhöht sich dezimal der Wert der IP Packet ID bei jedem Schritt um jeweils 255 (statt um 1). In der Praxis bedeutet das: Es wird nicht wie folgt gezählt: 0x0173, 0x0174, 0x0174 usw., sondern 0x0173, 0x0273, 0x0373 usw. – wobei der Wert des Lo-Bytes völlig zufällig ist.

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

Beim vorliegenden Windows XP-Client zeigt sich das Verhalten, dass er zwar korrekt den Zähler der IP Packet ID als 16-Bit-Zähler bedient (wie Windows 2000 auch), dass er aber folgenden Fehler dabei macht: Immer, wenn beim Lo-Byte (dem niederwertigen der zwei Bytes) der Wechsel von 0x09 auf 0x0A anstünde (und danach folglich auf 0x0B), kommt stattdessen die folgende Zählung heraus: 0x09, 0x16, 0x0B ... Mit Bezug auf die WORD-Zähler also: 0x0209, 0x0216, 0x020B usw. oder: 0x0309, 0x0316, 0x030B usw. Man muss schon viel Fantasie haben, um sich vorzustellen, welcher Bug da im Programm-Code die Bits angefressen hat! Dieser Befund wird für den Leser wenigstens teilweise über die Abbildung 14.106 nachvollziehbar: Zwei Pakete, deren IP Packet ID in verdrehter Reihenfolge zu sein scheinen, sind ausweislich der TCP Sequence Number (dem Sende-Offset) tatsächlich in der Reihenfolge ihres Eintreffens am Messpunkt vom Absender verschickt worden und der Wert von IP TTL = 128 zeigt, dass kein Routing-Hop stattgefunden hat. ■

Eine Durchsicht aller Pakete beweist (hier nicht zu sehen), dass tatsächlich über die gesamte Dauer hinweg das beschriebene Verhalten nachweisbar ist. Warum wird darüber solange gesprochen? Selbst, wenn ... wäre es nicht egal? Würde nicht jeder IP-Empfänger verdrehte Pakete wieder in der richtigen Reihenfolge zusammensetzen? Nun: Ausweislich der TCP Sequence Number wird dies wohl so sein. Und doch: Der Verfasser hat in den letzten ein, zwei Jahren Applikationen erlebt, die Abbrüche erlitten, weil die beteiligten Rechner eben doch nicht so tolerant mit Paketen umgingen, die in ihrer Reihenfolge verdreht waren. Dies führt zu allgemeiner Vorsicht – und dazu, solche Ereignisse ernst zu nehmen und ihnen möglichst auf den Grund zu gehen. Der aktuelle Fall hat denn ja auch gezeigt, dass wir zwar ein mehr oder weniger vernachlässigenswertes Ereignis vermuteten, am Ende aber auf einen interessanten internen Fehler des WinXP-Systems stießen und hier stellt sich immer gleich die Frage: Welcher Fehler im Software-Code löst diesen Fehler aus? Könnte dieselbe Ursache noch andere, wesentlich gefährlichere Fehler zur Wirkung haben? Man ist also nicht immer gut beraten, unter dem Zeitdruck des Tagesgeschehens vermeintlichen Kleinigkeiten nicht nachzugehen – genaues Hinsehen lohnt sich öfter, als man denken mag. Selbstverständlich (und jetzt folgt wieder das ceterum censeo des Autors :-) verlangt das nach einem Werkzeug, welches eine schnelle und klare Analyse bestmöglich unterstützt. Der Fall ist also geklärt und es zeigt sich: Die TraceMagic-Auswertung war völlig richtig, nur war die Ursache nicht im üblichen Spektrum der LAN/WANEreignisse zu suchen, sondern (mal wieder, wie so oft) auf der Microsoft-Baustelle namens Windows. Nach der ersten Auflage dieses Buches schrieben Leser, dass sie den Unterhaltungswert des Networker’s Guide für mindestens genauso hoch einschätzten wie dessen fachlichen Gehalt. Kein Wunder: Microsoft liefert immer wieder neuen Stoff für die funkelnden Auges weitergetragenen Erzählungen am romantischen Lagerfeuer der IT!

>>> NEW TECH

603

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.104: EventFilter: Filter auf IP Packets ID/Poss. Sort Error(s)

14.4.10 Router meldet: TTL = 0/Paket wurde verworfen Bereits im Zuge der Durchsicht der Gesamtstatistik in Tabelle 1 der TraceStatistics (siehe Abbildung 14.48 in Abschnitt 14.3.5) war aufgefallen, dass es eine ICMP-Meldung gegeben hatte – und zwar dergestalt, dass ein Router die Mitteilung machte, dass er ein IP-Paket habe verwerfen müssen, weil der TTL-Wert auf Null gefallen war. Der TTL-Wert wird seitens des IP-Absenders üblicherweise auf einen der folgenden Werte gesetzt: 255, 128, 64, 32 und so fort. Dieser Time-To-Live-Parameter stellt einen so genannten Hop Credit dar: Er erlaubt dem IP-Paket, so viele Router-Hops zu absolvieren, wie noch TTL-Punkte übrig sind, wobei jeder Router den TTL-Wert mindestens um den Wert 1 vermindert (Hop Cost). Trifft nun die Meldung eines Routers ICMP: Packet discarded/TTL = 0 ein, so gibt es verschiede Möglichkeiten, warum das so geschah. Die gängigsten Varianten sind: ■

604

Der Weg vom Absender bis zum Empfänger lief über zu viele Router. Diese Variante ist nur sinnvoll anzunehmen, wenn der Ausgangswert sehr knapp war, etwa TTL = 16 oder TTL = 32, denn selbst im WWW werden die meisten Webserver noch mit weniger als 32 Router-Hops erreicht, sicher aber mit weniger als 64 Router-Hops.

>>> NEW TECH

TraceMagic/Event-Log und EventFilter

Abbildung 14.105: Event-Log: Auffällig oft findet ein (echter? scheinbarer?) Rücksprung in der IP Packet ID mit der Differenz von 11 statt; dies wirft die Frage auf, ob es sich wirklich um eine Verdrehung der IP-Paketreihenfolge handelt. Die nähere Untersuchung zeigt: Es ist ein interner Windows XP-Fehler. ■

Es gibt eine Unklarheit in der Wegeführung; mindestens einer der beteiligten Router weiß nicht, wohin mit dem Paket; er gibt aber nicht die Meldung zurück ICMP: Network unreachable, sondern leitet das IP-Paket an einen anderen Router weiter, der für unknown Routes zuständig ist (weswegen die Meldung ICMP: Network unreachable eben auch unterbleibt). Wenn dieser nächste Router aber seinerseits genauso handelt, gibt es niemals die Meldung ICMP: Network unreachable, sondern am Ende die Meldung ICMP: Packet discarded/TTL = 0.

Hier interessiert am Ende nur noch: Sind es meine eigenen Router, die nicht wissen, wohin sie das IP-Paket leiten sollten oder findet das fern draußen in fremden Netzen statt? Also muss man mal genau(er) hinsehen. Kein Problem: Ein Blick in das ICMPEvent-Log zeigt, dass es sich um einen lokalen Router handelt (siehe Abbildung 14.107). Also: Alarm! Was ist da schief gelaufen? Hierzu muss ein Blick in das Gesamt-Event-Log geworfen werden – oder gleich in den Original-Trace (siehe Abbildung 14.108).

>>> NEW TECH

605

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Abbildung 14.106: Der Frame 1126 trägt die IP Packet ID 534, der Frame 1128 die IP Packet ID 523 – und das bei gleichzeitig aufwärts gezählter TCP Sequence Number, was beweist, dass die beiden Pakete tatsächlich in dieser Reihenfolge abgesendet wurden. Der Wert von TTL = 128 zeigt, dass kein Routing-Hop stattgefunden hat.

Abbildung 14.107: Event-Log: Die Meldung »ICMP: TTL = 0« stammt von einem Router des Campus-LANs.

Es zeigt sich: Zwischen den Teilnehmern IP = 192.168.2.195 und IP = 192.168.192.2 läuft ein SMB-Dialog – wenngleich auch nur spärlich Pakete ausgetauscht werden. Jedenfalls werden einige IP-TCP-SMB-Pakete ausgetauscht, bis schließlich der Client IP = 192.168.2.195 in Frame 7331 das IP-Paket mit der ID = 3220 an Server IP = 192.168.192.2 schickt. Genau dieses IP-Paket, das mit TTL = 128 versendet wurde, strandet bei Router IP = 192.168.250.97 mit TTL = 0, also erzeugt der Router die besagte ICMP-Meldung (die im Anhang eine Kopie des verworfenen Pakets bzw. von dessen IP-Header enthält).

606

>>> NEW TECH

Fazit der Fallstudie

Abbildung 14.108: Der Router meldet ICMP: TTL = 0 für ein IP-Paket, das völlig normal innerhalb einer aktiven SMB-Sitzung gesendet wurde, die zwischen IP = 192.168.2.195 und IP = 192.168.192.2 betrieben wird.

Da keine weiteren Messdaten von anderen Punkten des Netzwerkes zur Verfügung stehen, ist ohne weitere Hinweise (etwa: Router-Log) nicht mehr entschlüsselbar, was zu diesem Verhalten geführt hat. Verwunderlich ist offensichtlich, dass zwischen den beiden Endpunkten die IPTCP-SMB-Pakete einwandfrei ausgetauscht werden konnten – nur eben jetzt, ganz plötzlich, nicht mehr. Die Wahrscheinlichkeit spricht dafür, ■ ■ ■

dass es einen spontanen Ausfall irgendeiner Komponente gegeben hat, dass daraufhin ein anderer Verkehrsweg als üblich verwendet wurde, dass auf diesem Ersatzweg einer der beteiligten Router nicht mehr weiter wusste und das IP-Paket im Kreis umhergeschickt hat, bis mit TTL = 0 das Verfallsdatum erreicht war.

14.5 Fazit der Fallstudie Wir haben aus einem verhältnismäßig kurzen Trace von nur 7.349 Frames ein ansehnliches Panoptikum interessanter und aufschlussreicher Fehler isoliert. Vieles davon ist absolut repräsentativ für die typischen Netzwerk-Umgebungen unserer Zeit (Stand 2002). Wir konnten erkennen, dass es einige unerfreuliche

>>> NEW TECH

607

Kapitel 14 • OSI-Schicht 7: Fallstudie Windows XP-Client

Fehler gibt, die selbst bei Win2K bzw. WinXP auftreten oder sogar typisch sind. Und wir haben zeigen können, dass das verwendete Werkzeug alles dies zeigen konnte. Gleichzeitig sind wir auch, was den Unterhaltungswert anbelangt, vollkommen auf unsere Kosten gekommen, denn man will ja immer auch was für die Augen haben – nur satt werden reicht nicht! Und der Verfasser kann natürlich mal wieder nicht an sich halten und muss auf die Analyzer der etablierten Hersteller einprügeln: Selbstverständlich hätte ein marktüblicher Analyzer während der OnlineMessung das eine oder andere angezeigt, etwa, dass es die Meldung ICMP: TTL=0 gegeben hat. Spätestens jedoch in der Offline-Analyse wäre bei einem Volumen von einigen hundert Trace-Dateien jede Chance verloren gewesen, mal eben so zum Ergebnis zu kommen. Effizienz unter den Bedingungen hoher Ausfallkosten bedeutet, nicht nur irgendwie und irgendwann zu einem Ergebnis zu kommen, sondern praktisch die Garantie zu haben, alle wesentlichen Ereignisse und Fundstellen herauszufinden, gleich, wo sich das alles in 10 oder 50 Gigabytes von Messdaten verbirgt. Daher sollte dieses Kapitel auch die Verfahrensweisen und Bearbeitungsschritte darstellen, mit denen diese Ergebnisse erreicht werden können; diese müssen unter (fast) allen Bedingungen vom Aufwand her berechenbar, in der Darstellung bzw. im Ablauf klar gegliedert und – vor allem für Dritte, denen die Ergebnisse später vorgelegt werden – nachvollziehbar bzw. jederzeit verifizierbar sein. Wir wollen ja nicht nur Entstörung nach dem Crash leisten, sondern auch – und vor allem – Vorbeugung vor dem Crash (der dann hoffentlich bzw. wahrscheinlich gar nicht erst stattfindet). Das geht aber nur, ■ ■ ■ ■

wenn der Aufwand begrenzt ist, wenn das erforderliche Fachwissen als Eingangsvoraussetzung nicht zu hoch sein muss, wenn mit einem erträglichen Trainingsaufwand schnell eine hochwertige Analyse erreicht werden kann, wenn das Werkzeug alles dies für die tägliche Praxis optimal unterstützt – und nicht nur für die zwei Tage im Jahr, wo ein Mega-Crash den Netzwerker veranlasst, sich wieder mit gequältem Gesichtsausdruck vor seinen Analyzer zu setzen.

Dieses Kapitel sollte zeigen – und hat das hoffentlich auch erreicht –, dass und wie dies alles geleistet werden kann. Gute und ständig begleitende LAN-Analyse im Sinne von Qualitätssicherung bzw. revisionsfester Aussagen ist kein Wunder, sondern ohne allzu großen Aufwand machbar: wenn das Werkzeug stimmt.

608

>>> NEW TECH

Kapitel 15 OSI-Schicht 7: Fallstudie Voice over IP Quelle: Castrop-Rauxel 2002

Diese Fallstudie entstand im Herbst 2002. Die Situation: Ein Kunde steckt mitten in der Einrichtung eines deutschlandweiten Voice over IP-Projekts. Die Zentrale soll mit den Niederlassungen wie folgt verbunden werden: Die Telefonverbindungen sollen nicht mehr über das öffentliche Fernsprechnetz laufen, sondern über das unternehmenseigene Datennetz.

15.1 Das VoIP-Projekt: Ausgangslage Sowohl der Hersteller der Telefonanlagen ist beteiligt wie auch ein RouterHersteller; beide Hersteller liefern VoIP-fähige Komponenten. Teilweise sollen die Endpunkte der VoIP-Verbindungen direkt in den Telefonanlagen liegen (Variante A), teilweise sollen die Telefonanlagen ihre ISDN-Daten an die VoIP-fähigen Router weitergeben, wo dann erst die Sprache auf VoIP umgesetzt wird (Variante B). Beide Varianten sollen getestet werden, um ihre Zuverlässigkeit parallel ermitteln zu können. Seit zwei bis drei Wochen steckt das Projekt fest, da es immer wieder zu schlechter Sprachqualität sowie zu Verbindungsabbrüchen kommt. Weiterhin geschieht es, dass mitten im Gespräch zwischen Niederlassung West und Niederlassung Ost der Teilnehmer in Niederlassung West einen Teilnehmer aus Niederlassung Süd am Hörer hat – offenkundig springen die Telefonsitzungen bisweilen wild durcheinander. Der Hersteller der Telefonanlagen (ein nicht unbedeutender, allseits bekannter Hersteller) hat sowohl in der Hauptstelle als auch in der Niederlassung in Castrop-Rauxel (wo der unten beschriebene Trace entstand) jeweils einen Laptop installiert, um VoIP-Verbindungen zu simulieren. Es wurden bislang Paketverluste festgestellt, sonst aber nichts weiter. Alle Beteiligten (Kunde und Hersteller) haben verschiedene Messungen angestellt, sind aber nicht zu Erkenntnissen gekommen, die es erlaubt hätten, die Fehler abzustellen bzw. die erwünschte Sprachqualität in den VoIP-Verbindungen sicherzustellen. Unter diesen Verbindungen wurde eine Zangenmessung vorgenommen: vier Stunden lang in Castrop-Rauxel, zeitgleich in der Hauptstelle des Unternehmens. >>> NEW TECH

609

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Es kamen ein paar nicht erwartete Ergebnisse dabei heraus. Vor allem konnten Aussagen getroffen werden, die nicht nur die Symptome bzw. deren Beschreibung betrafen, sondern die auf Ursachen und Wechselwirkungen hinwiesen. Diese Fallstudie beschäftigt sich zwar auch mit Voice over IP, handelt aber zu großen Teilen von ganz anderen Protokollen und Ereignissen – nämlich solchen, die u.a. dafür verantwortlich waren, dass diese Missstände auftraten.

15.2 Voice over IP: RTP und RTCP 15.2.1 TCP: Steuerdaten der VoIP-Endpunkte Die VoIP-Endpunkte kommunizieren mit einem Steuerungsprotokoll über TCP, wenn es sich um den Austausch von Steuerdaten handelt (Verbindungsauf- und -abbau). Da die LAN-Analyzer diese Dialoge nicht dekodier(t)en, ist dieser Teil der Kommunikation nicht bis ins Letzte nachvollziehbar.

15.2.2 UDP und RTP (Real Time Protocol) Die eigentlichen Sprachdaten werden via RTP (Real Time Protocol) übertragen. In fest eingestellten Intervallen wird jeweils eine kleine Sprachinformation übertragen. Für die Sprachqualität ist von entscheidender Bedeutung, dass die RTP-Pakete ohne nennenswerte Verzögerung bzw. Laufzeit (Delay) und ohne größere Schwankung dieser Laufzeit (Jitter) das Netzwerk von Ende zu Ende durchlaufen. Paketverluste sind in kleinerer Zahl verschmerzbar, weil das menschliche Ohr auf geringe Verluste entweder träge reagiert (sie also gar nicht wahrnimmt) oder weil das menschliche Gehirn kleine Aussetzer so korrigiert, dass es der Mensch oft bewusst gar nicht wahrnimmt. Hier ist also die Untersuchung des Zeitverhaltens von Belang wie ggf. auch die Erfassung von Paketverlusten.

15.2.3 UDP und RTCP (Real Time Control Protocol) Ebenfalls in festen Intervallen tauschen die VoIP-Endpunkte Steuerdaten aus, mit denen der aktuelle Sitzungsstatus mitgeteilt wird. Dies geschieht via RTCP (Real Time Control Protocol). Über RTCP werden Paketverluste mitgeteilt ebenso wie zeitliche Schwankungen bei den einlaufenden RTP-Paketen, das heißt Abweichungen vom festen Zeittakt, in welchem die RTP-Pakete des jeweils gegenüber liegenden VoIP-

610

>>> NEW TECH

Analyse in Castrop-Rauxel (Niederlassung)

Endpunktes eigentlich eintreffen sollten. Das bedeutet mit anderen Worten: Die RTCP-Meldungen geben klar Auskunft über die Qualität der RTP-Verbindungen des jeweils empfangenden VoIP-Endpunktes. Als VoIP-Endpunkt gilt entweder eine direkt selber mit RTP arbeitende Telefonanlage oder ein RTP-fähiger Router, der von der Telefonanlage die Sprachdaten übernimmt (bzw. sie wieder dorthin zurückgibt).

15.2.4 UDP-Ports für RTP und RTCP Für die RTP-Sitzungen werden keine fest eingestellten Port-Nummern verwendet. Stattdessen werden die Port-Nummern dynamisch zugewiesen bzw. nach und nach hochgezählt. Ein Standardfall sieht wie folgt aus: ■ ■ ■

Die erste RTP-Sitzung arbeitet über UDP-Port 4000, die dazu gehörenden RTCP-Meldungen über UDP-Port 4001. Die zweite RTP-Sitzung arbeitet über UDP-Port 4002, die dazu gehörenden RTCP-Meldungen über UDP-Port 4003. Und so fort.

Es können aber auch UDP-Ports weitab davon auftreten; dies hängt u.a. von den Einstellungen der Geräte ab. Das führt dazu, dass es keine Chance gibt, die via RTP arbeitenden VoIP-Sitzungen per Port-Filter aus dem Datenstrom zu isolieren. TraceMagic ist in der Lage, eine vom Anwender vorgegebene Port-Range zu akzeptieren, kann aber auch per Auto-Detection die verwendeten RTP-RTCPPorts selber herausfinden (das gilt übrigens auch für die HTTP-Proxy-Ports).

15.3 Analyse in Castrop-Rauxel (Niederlassung) Die folgenden Abschnitte zeigen, wie der Reihe nach den Hinweisen nachgegangen wurde und welche Ergebnisse dabei erzielt wurden.

15.3.1 Der Messpunkt Der Messpunkt in der Niederlassung in Castrop-Rauxel ist ein Mirror-Port am LAN-Switch, der die Verbindung zum WAN-Router spiegelt. Der Mirror-Port gibt also alle LAN-Pakete aus, die aus dem LAN an den WAN-Router geleitet werden und umgekehrt. In der Niederlassung gibt es keinen weiteren Router, es gibt keine redundanten Doppelstrukturen. Dies ist für einige der Abläufe von Bedeutung.

>>> NEW TECH

611

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

15.3.2 TCP Window Size/TCP Keep Alive Schon gleich zu Beginn der Auswertung fällt auf, dass die TCP Window Size einiger Sitzungen immer wieder gering sind, außerdem fallen TCP Keep AlivePakete auf (siehe Abbildung 15.1). Da das jedoch den TCP-Port 515 betrifft und somit die Übertragung von Druckaufträgen über das Netzwerk, bleibt das zwar interessant, betrifft aber nicht die VoIP-Probleme. Gleichwohl ist es nicht falsch, auch die Auffälligkeiten und Fehler anderer Applikationen zu sehen, da schließlich die Ursachen der VoIP-Fehler auch Wirkungen auf das Verhalten anderer Anwendungen haben können.

Abbildung 15.1: Event-Log: TCP Window Size Zero; TCP Keep Alive Packets; nicht gerade untypische Erscheinungen beim Network Printing

15.3.3 SNMP mit Community public Nur so ganz nebenher fällt auf: Da werden SNMP-Komponenten mit dem Community String angesprochen, der als Systemvorgabe bzw. als Factory Setting ausgeliefert wird: public

Dies ist aus Sicherheitsgründen strikt abzulehnen! Jeder Hacker versucht zuerst, mit den Passworten public und private via SNMP Lese- und Schreibzugriff auf Router zu erlangen.

612

>>> NEW TECH

Analyse in Castrop-Rauxel (Niederlassung)

Abbildung 15.2: Event-Log: Die SNMP-Zugriffe arbeiten mit dem allgemein bekannten Community String (Passwort) public. Das ist aus Gründen der Sicherheit nicht wünschenswert.

15.3.4 Laufzeitschwankungen: VoIP-Analyse im Observer Der Observer (Network Instruments) gehört zurzeit (Stand 2002) zu den wenigen Analyzern, die bei der Analyse von VoIP echte Hilfe bieten. Das Zeitverhalten der RTP-Verbindungen wird gut dargestellt; entsprechend lassen sich schnell Aussagen über die Qualität der Sprachverbindungen machen. Jenseits dessen aber machen sich wieder die bekannten Schwächen des Observers bemerkbar: Er kann quantitative Elemente gut darstellen, bietet aber kaum eine Chance, an die Ursache etwaiger Fehler heranzukommen. Die Abbildungen zeigen die Herangehensweise im Observer und die Ergebnisse. Sie rechtfertigen den weiteren Aufwand, mit TraceMagic nach den Ursachen der starken Jitter-Effekte (Laufzeitschwankungen) zu suchen.

Abbildung 15.3:

Observer/VoIP-Analyse (1): Zunächst werden die UDP-Verbindungen auf allgemeine Effekte hin untersucht. In dieser Tabelle sind die Delay-Angaben nicht durchgängig angegeben.

>>> NEW TECH

613

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Abbildung 15.4: Observer/VoIP-Analyse (2): Ein Mausklick mit der rechten Maustaste ruft ein kontextsensitives Popup-Menü auf, über das die VoIP-Analyse mit Bezug auf die aktuell angewählte UDP-RTP-Sitzung gestartet werden kann.

Abbildung 15.5: Observer/VoIP-Analyse (3): Die Darstellung des RTP-Zeitverhaltens zeigt: Es gibt starke Jitter-Effekte (Laufzeitschwankungen) sowie Paketverluste.

614

>>> NEW TECH

Analyse in Castrop-Rauxel (Niederlassung)

Abbildung 15.6: Observer/VoIP-Analyse (4): Die Darstellung des RTCP-Zeitverhaltens zeigt: Es gibt auch hier starke Jitter-Effekte (Laufzeitschwankungen) sowie Paketverluste.

15.3.5 MAC-Fehler (und vermeintliche TCP/IP-Fehler) Angeblich: doppelte IP-Header Die IP-Analyse bringt zudem den Befund, dass IP-Header mehrfach auf der Leitung wären (siehe Abbildung 15.7, Pakete 3851 und 3858) – was nicht sein darf, da alle zulässigen Möglichkeiten für einen solchen Fall ausscheiden (etwa vermaschte Token-Ring-Segmente, sofern es sich bei den IP-Paketen um SourceRoute-Broadcast gehandelt hätte). Angeblich: TCP-Pakete als MAC-Multicasts Weiterhin wirft die TraceMagic-Analyse den Befund aus, dass TCP-Pakete bisweilen als MAC-Multicast unterwegs wären – was unter gar keinen Umständen zulässig wäre (siehe Abbildung 15.7, Paket 3858). Tatsächlich: MAC-Fehler Das Event-Log von TraceMagic weist an denselben Stellen, bei denen angeblich auch Fehler bei IP und TCP gegeben sind, Fehler auf Layer 1 bzw. 2 aus (Physical Layer, MAC Layer). Hierbei handelt sich um unzulässige Paketlängen, denn mit mehr als 6.000 Oktetten liegen zweifelsfrei defekte Ethernet-Pakete vor. Wie in Abbildung 15.7 zu sehen ist, treten einmal sogar vier Ethernet-Frames hintereinander mit derselben Deformation auf (Pakete 3855-3858); siehe hierzu auch Abbildung 15.8. >>> NEW TECH

615

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Ein kurzer Blick auf die vermeintlichen MAC-Adressen dieser Frames zeigt, dass hier tatsächlich etwas nicht stimmen kann: Denn solche Adapteradressen sind völlig unwahrscheinlich bzw. sogar unzulässig.

Abbildung 15.7: Event-Log: MAC-Fehler, IP-Fehler, TCP-Fehler: Echt oder unecht? Interessante Verschachtelungen von Fehlern und Symptomen

Paket 3858: angeblicher TCP-Multicast Eine Betrachtung von Paket 3858 zeigt: Der Ethernet-Frame ist an die (angebliche) Adresse MAC = 838104:BF04BF gerichtet. Die »3« im ersten Oktett (0x83) weist aus, dass in der MAC-Adresse das I/G-Bit auf 1 gesetzt ist (Individual or Group Address) und dass das U/L-Bit auf 1 gesetzt ist (Universally or Locally Administered Address). Diese beiden Bits sind nicht regulär gesetzt, sondern Folge einer Deformation des Ethernet-Frames. Entsprechend wird klar, dass das TCP-Paket nicht wirklich als Multicast adressiert , sondern verfälscht wurde (siehe Abbildung 15.10). Pakete 3847 und 3854: doppelter IP-Header Vergleicht man Paket 3847 mit Paket 3854 (was TraceMagic automatisch tut), zeigt sich, dass die IP-Header beider Pakete identisch sind – was, wie oben bereits beschrieben wurde, unter den gegebenen Verhältnissen völlig unzulässig ist. Die Textausgabe des Event-Logs besagt: IP Hdr.Dupl./Poss.MAC mult.Tx / ID: 40058

IP Header Duplicated/Possible MAC multiple Transmission/Packet ID: 40058 Da angesichts sich überlagernder Fehlerbilder die Möglichkeit von Fehldeutungen besteht, bleibt nichts anderes übrig, als in die Pakete direkt hineinzusehen, um sich Klarheit zu verschaffen (siehe Abbildung 15.9). Es zeigt sich: Die IPHeader beider Pakete sind tatsächlich identisch. Sie unterscheiden sich jedoch in einem wesentlichen Merkmal: ■ ■

616

Paket 3847 ist korrekt und ohne Schaden. Paket 3854 ist defekt und weist Überlänge auf. >>> NEW TECH

Analyse in Castrop-Rauxel (Niederlassung)

■ ■ ■ ■

Daraus können folgende Schlüsse gezogen werden: Paket 3847 wird tatsächlich als Paket 3854 ein zweites Mal gesendet. Die Zweitübertragung erfolgt mit Deformation des Ethernet-Frames. Die Deformation sieht so aus, dass willkürlich Daten angehängt werden, was die Überlänge erklärt.

Somit ist klar, dass der Switch, an welchem der Analyzer angeschlossen ist (Mirror Port), defekt sein muss. Ein Irrtum ist ausgeschlossen. Verfälschungen und Vervielfältigungen Die Auswertung der Messdaten zeigt: Es treten sporadisch Verfälschungen und Vervielfältigungen von Ethernet-Frames auf; diese Phasen sind unterschiedlich lang. Es ist klar: Wenn ein solcher Zustand länger andauert, können viele Pakete auf die Weise verloren gehen, ■ ■

dass auch TCP-Sitzungen im Abbruch enden können, dass Voice over IP-Sitzungen spontanen Qualitätsverlust erleiden können.

Der Kunde beschließt, den Switch-Typ gegen einen anderen austauschen zu lassen (was der Hersteller zu tragen hat, da es ein Fall der Gewährleistung ist). Da derselbe Switch-Typ in fast allen Niederlassungen steht, kann dies einerseits einen Teil der beklagten Fehler erklären und dürfte andererseits für den Lieferanten bzw. Hersteller etwas teuer geworden sein.

Abbildung 15.8: Vergleich der Pakete 3854 und 3855: Beide Ethernet-Frames weisen unzulässige Überlängen auf.

>>> NEW TECH

617

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Abbildung 15.9: Vergleich der Pakete 3847 und 3854: Die IP-Header sind identisch, wie sich u.a. an der identischen Paketnummer (40.058) zeigt.

Abbildung 15.10: Der angebliche TCP-Multicast erweist sich als Deformation eines Ethernet-Frames.

618

>>> NEW TECH

Analyse in Castrop-Rauxel (Niederlassung)

TraceMagic-Statistiken am Beispiel von IP = 192.168.80.106 Um zu zeigen, dass klare Befunde keine Glückssache sind, sondern das Ergebnis systematischen Vorgehens, wird hier die Beweiskette vom ersten Hinweis bis zur letzten Verifikation nachvollzogen. Die Verfahrensweise ist meistens gleich: ■ ■

■ ■ ■ ■

Zuerst fallen einige Hinweise im Event-Log auf (noch während die TraceMagic-Analyse läuft). Daher sieht man sich die Statistiken der TCP/IP-Auswertung mit besonderer Aufmerksamkeit an. Dies kann mit dem TraceStatistics-Datenbank-Modul geschehen (erlaubt Suchen und Sortieren in den Tabellen sowie den Zugriff auf die Knowledgebase bzw. Wissensdatenbank) oder aber mit den ReportDateien in den Formaten .TXT und .CSV, die einige Zusatzangaben enthalten, die sich im Datenbankformat nicht darstellen lassen. Diese TCP/IP-Report-Dateien sind in drei Abschnitte eingeteilt: Erstens eine Gesamtstatistik aller Auffälligkeiten und Fehler Zweitens ein Nachweis aller beteiligten IP-Adressen je Symptom und Fehler Drittens ein Einzelnachweis für jeden der max. 65.500 IP-Hosts, für die TraceMagic die Ergebnisstatistiken führen kann

Eine Durchsicht dieser drei Gliederungsebenen führt vom Allgemeinen zum Besonderen bzw. hilft, Fehlerklassen auf die beteiligten IP-Hosts herunterzubrechen. Demselben Schema folgen übrigens auch die verschiedenen Tabellen der TraceStatistis-Datenbanken. Die Logik des Vorgehens ist also in beiden Fällen gleich.

Abbildung 15.11: Event-Log: Hinweise auf Pakete mit verdoppelten IP-Headern

Nach Durchsicht der TraceMagic-Reports empfiehlt es sich, in schwierigen Fällen die eine oder andere Fundstelle manuell nachzuprüfen, um die Korrektheit des Befundes (bzw. der daraus abgeleiteten Vermutungen) sicherzustellen. In diesem Fall wird die Paketverdopplung genauer betrachtet, um Hinweise auf Ursachen und Wechselwirkungen zu erhalten. Es zeigt sich im Original-Trace, dass nur ein physikalischer Fehler des Switches die Daten erklären kann. Es kann müßig bleiben, darüber nachzusinnen, ob der Switch diese Vervielfältigung und Verfälschung von IP-Paketen nur am Mirror-Port gegenüber dem Analyzer praktiziert oder auch auf den anderen, normalen Client-Ports.

>>> NEW TECH

619

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Abbildung 15.12: TraceMagic/TCP/IP-Auswertung: Es fallen 14 IP-Header-Verdopplungen auf sowie 6 TCP-Multicasts; beides ist unzulässig.

Fakt ist: Ein Switch, der ein solches Verhalten zeigt, ist zweifellos defekt und gehört ausgetauscht. Dieses geschah in diesem Falle auch. Da viele Niederlassungen mit demselben Switch-Typ ausgestattet waren, wurde dies für den Hersteller ein teueres Geschäft. Ein Treppenwitz der ganzen Geschichte ist, dass seit über einer Woche eine spezielle Analyse-Software eines der beteiligten Lieferanten auf dem Laptop mitlief – aber entdeckt wurde von alledem nichts (nicht die IP-Fehler, nicht die TCPFehler, nicht die MAC-Fehler). Wofür bezahlt der Kunde eigentlich das teure Geld? In Falle dieses speziellen Fehlers hätte es übrigens nicht unbedingt gereicht, die internen Switch-Statistiken über TELNET oder HTTP abzufragen, denn interne Fehler dieser Art werden erfahrungsgemäß nicht zuverlässig vom Switch selber erkannt.

620

>>> NEW TECH

Analyse in Castrop-Rauxel (Niederlassung)

Abbildung 15.13: TraceMagic/TCP/IP-Auswertung: Insgesamt waren 8 TCP-Paketverdopplungen zu beobachten. Außerdem fallen einige Werte für die TCP Window Size auf (536, 576), die ggf. Hinweis auf MTU-Probleme der WAN-Router sein könnten (Black Hole Scenario).

Die Alternative dazu wäre, die Statistiken eines gegenüber liegenden Switches oder Routers mittels TELNET oder HTTP abzufragen – denn dort müssten ja diese verfälschten und verdoppelten Pakete eintreffen und wenigstens die Überlängen müssten dort erkannt werden. Im aktuellen Fall jedoch war dies dem Kunden nicht möglich, da es in der kleinen Niederlassung in Castrop-Rauxel nur diesen einen Switch gab und gegenüber lag eben nur der WAN-Router, der nicht in der Verwaltung des Kunden stand, sondern allein unter der Hoheit des WAN-Providers stand.

>>> NEW TECH

621

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Abbildung 15.14: TraceMagic: Die Statistiken der TCP/IP-Auswertung zeigen an, dass die Pakete verschiedener IP-Teilnehmer doppelte IP-Header enthalten.

Abbildung 15.15: TraceMagic: Die Statistiken der TCP/IP-Auswertung weisen für IP = 192.168.80.106 mehrere MAC-Adressen aus – was gar nicht sein kann. Außerdem sehen einige dieser MAC-Adressen stark zweifelhaft aus, da die letzten drei Oktette jeweils identisch sind und die ersten drei Oktette nicht nach den üblichen Hersteller-Codes aussehen!

Abbildung 15.16: TraceMagic/TCP/IP-Auswertung: Die TCP-Multicasts betreffen die Pakete der beiden IP-Teilnehmer IP = 192.168.80.98 und IP = 192.168.80.106.

622

>>> NEW TECH

Analyse in Castrop-Rauxel (Niederlassung)

Abbildung 15.17: TraceMagic/TCP/IP-Auswertung: Die Nachweisliste aller TCP-Symptome zeigt ansonsten für IP = 192.168.80.106 ein völlig fehlerfreies TCP-Verhalten.

Abbildung 15.18: TraceMagic: Einzelnachweis (1) für den Host IP = 192.168.80.106; auch hier fallen die angeblichen MAC-Adressen auf, ebenso wie die 5 erkannten IP-Header-Verdopplungen und die 5 TCP-Multicasts (die es nie geben darf). >>> NEW TECH

623

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Abbildung 15.19: TraceMagic: Einzelnachweis (2) für den Host IP = 192.168.80.106; die TCP-Statistiken weisen aus, dass 5 TCP-Pakete unzulässige Verdopplungen waren.

Daraus ließen sich – zur Erschütterung wie auch Erheiterung des Kunden, mit dem das alles selbstverständlich gründlich erörtert wurde – nur folgende Schlussfolgerungen ableiten: ■

■

624

Der WAN-Router des WAN-Providers hat die Fehler gar nicht erkannt; die Statistiken haben keinen Empfang von überlangen Paketen erkannt. Diese Variante ist eher unwahrscheinlich. Der WAN-Router hat sehr wohl die defekten Pakete, die er vom gegenüber liegenden LAN-Switch geliefert bekam, erkannt und in seinen Statistiken abgebildet. Nur der WAN-Provider hat die Router-Statistiken einfach nicht abgefragt oder nicht verstanden! Diese Variante ist absolut die wahrscheinlichere.

>>> NEW TECH

Analyse in Castrop-Rauxel (Niederlassung)

Abbildung 15.20: Original-Trace (1): Schon die angeblichen Werte mit EtherType 0xFFFF lassen Zweifel aufkommen, ob hier tatsächlich alles korrekt abläuft: Vielmehr stellt sich der Verdacht auf Frame-Deformationen auf dem Physical Layer ein.

Abbildung 15.21: Original-Trace (2): Es wird ein Filter gesetzt auf die TCP Sequence Number (0x0F3E8BD8) eines betroffenen TCP-Pakets. Im Ergebnis werden alle Pakete angezeigt, welche diese Hex-Folge enthalten.

>>> NEW TECH

625

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Abbildung 15.22: Original-Trace (3): Drei IP-Pakete, welche denselben TCP-Header enthalten, werden verglichen. Die unteren Fenster mit dem jeweiligen Hex-Dumps der Pakete zeigen Unterschiede in Länge und Inhalt der Pakete.

Abbildung 15.23: Original-Trace (4): Das erste TCP-Paket (# 10.362) ist korrekt formatiert und einwandfrei; die beiden anderen Pakete (# 10.369, 10.376) sind verlängert. Dass trotzdem vom Analyzer für alle drei Pakete die Nutzdatenmenge von 148 Byte angezeigt wird, geht auf die in allen drei Paketen identischen Angaben im IP-Header zurück (hier nicht zu sehen). Klar ist, dass die beiden Folgepakete (a) Verdopplungen des ersten Pakets sind und gleichzeitig (b) Verfälschungen desselben, insofern fremde Daten angehängt wurden.

626

>>> NEW TECH

Analyse in Castrop-Rauxel (Niederlassung)

Abbildung 15.24: Original-Trace (5): Eine Betrachtung der MAC-Header und IP-Header zeigt: Die IP Packet ID ist mit ID = 3.244 in allen Fällen identisch. Nur der erste Ethernet-Frame ist gesund; die beiden Verdopplungspakete weisen völlig unzulässige Überlängen auf. Schlussfolgerung: Der Switch weist zwei Fehler auf. (A) Er schickt spontan Pakete mehrfach auf die Leitung. (B) Er verfälscht Pakete durch Anhängen von Zufallsdaten.

Wie kann es sein, dass der Kunde viel Geld für die WAN-Anbindungen bezahlt und für das damit gleichzeitig eingekaufte Management, wenn der WAN-Provider noch nicht einmal in der Lage ist, dermaßen grundlegende Dienste zu erbringen? Um keinem Missverständnis aufzusitzen: Es geht nicht darum, im laufenden Betrieb verdachtsweise nach extrem seltenen Fehlern zu suchen. Es geht um die Handlungsweise im Störfall! Hier handelte es sich um eine bereits seit rund drei Wochen andauernde Fehlersuche, weil das Voice over IP-Projekt wegen gravierender Fehler gewaltig ins Rutschen zu kommen drohte und alle beteiligten Parteien seit Wochen damit beschäftigt waren, Fehleranalyse zu betreiben! Hier zweifelt man manchmal wirklich am Verstande der einen oder anderen Vertragspartei. Der Verfasser kann dem Leser den Hinweis nicht ersparen, dass dieser WAN-Provider (dessen Name hier bewusst nicht genannt wird) bei einer wirklich großen Zahl von Kunden mit derlei Mega-Fehlern auffällig wurde. Das alles ist wirklich nicht mehr erfreulich.

>>> NEW TECH

627

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

15.3.6 IP-Pakete treffen in verdrehter Reihenfolge ein Die Betrachtung der IP-Ereignisse zeigt schnell, dass IP-Pakete in verdrehter Reihenfolge am Messpunkt eintreffen. TraceMagic prüft, ob es bei der Zählung der IP-Paketnummern (IP Packet ID) zu Rückschritten kommt, wobei einige Besonderheiten zu berücksichtigen sind: ■ ■

■

■

■

■

■

■

628

Die IP-Paketnummern werden wie folgt gezählt: 0..65.535 (0x0000-0xFFFF). Bei Erreichen von 0xFFFF wird zurückgesprungen auf 0x0000 oder 0x0001. Wann immer in einem IP-Paket eines bestimmten IP-Absenders die Packet ID kleiner ist als im vorigen IP-Paket desselben IP-Absenders, wird das Ereignis von TraceMagic überprüft bzw. bewertet. Ist der vorige ID-Wert nur wenig kleiner als 65.535 und der nachfolgende ID-Wert nur wenig größer als 0 bzw. 1, so ist davon auszugehen, dass der numerische Rückschritt tatsächlich nur durch den normalen Zählerüberlauf stattgefunden hat. Dies ist kein Fehler, sondern unvermeidlich. Ist davon auszugehen, dass ein Zählerüberlauf eher unwahrscheinlich ist, wird von einem möglichen IP-Paketdreher ausgegangen (meistens die Folge von verschiedenen IP-Routen im WAN). In diesem Falle wird geprüft, ob die beiden IP-Pakete, die verglichen werden, an denselben Empfänger gerichtet waren (oder nicht). Sind sie an denselben IP-Host adressiert, bleibt es beim Befund, dass es sich um eine verdrehte Reihenfolge der Pakete handelt. Sind die zwei Pakete jedoch an zwei verschiedene IP-Hosts adressiert, ist mit der Möglichkeit zu rechnen, dass der Absender für jeden einzelnen IP-Empfänger eine eigene, getrennte Zählung der IP-Paketnummern durchführt. Für diesen Fall ist die Prüfung auf Verdrehung der IP-Pakete auszudehnen, indem die Paketnummern je Dialogbeziehung bewertet werden. Sind beide IP-Pakete an denselben Empfänger adressiert und ist die Differenz der Paketnummern sehr gering (was einen Paketdreher wahrscheinlich macht), so gibt TraceMagic im Event-Log den Differenzwert zusätzlich aus, um auf die erkennbar starke Wahrscheinlichkeit des Befundes aufmerksam zu machen. Beträgt die Differenz -1 (siehe Abbildung 15.25), so ist mit an Sicherheit grenzender Wahrscheinlichkeit davon auszugehen, dass eine Verdrehung der IP-Paketreihenfolge stattgefunden hat – vermutlich in der Form, dass die beiden Pakete in einem vermaschten IP-Routing-Netz (eher WAN als LAN) verschiedene Wege durchliefen und daher das zweite Paket das erste überholen konnte. Eine andere Variante wäre (was in seltenen Fällen vorkommt), dass im Paket-Puffer eines Switches oder Routers das FIFOVerfahren (First-In, First-Out) verletzt worden wäre. Beträgt die Differenz der beiden IP-Paketnummern genau -255, so ist das wie -1 zu bewerten, da bis einschließlich Windows NT 4 die älteren Windows-Versionen die IP-Paketnummer beim Hochzählen nicht mit +1 erhöhen, sondern mit 256 (0xFF), da der Zwei-Byte-Zähler (WORD) nur im HiByte erhöht wird, nicht jedoch im Lo-Byte.

>>> NEW TECH

Analyse in Castrop-Rauxel (Niederlassung)

■

Beträgt die Differenz der beiden IP-Paketnummern genau -11, so könnte es sich um einen Windows-XP-Fehler beim Zählen der IP-Paketnummern handeln; siehe hierzu die Windows-XP-Fallstudie. Dann nämlich wird wie folgt gezählt (Beispiel): 0x0208, 0x0209, 0x0216, 0x020B, ... der Wert von 10 bzw. 0x0A im Lo-Byte wird fälschlicherweise ersetzt durch den Wert von 22 bzw. 0x016 und somit ergibt sich (um im Beispiel zu bleiben) zwischen 0x0216 und 0x020B bzw. 534 und 523 eine Differenz von 11 und also erscheint es so, als sei der IP-Paketzähler von einem Paket zum anderen nicht erhöht, sondern um den Wert von 11 vermindert worden.

Nun ist es so, dass tatsächlich mehrfach Ereignisse nachweisbar sind, bei denen jeweils zwei IP-Pakete desselben Absenders an denselben Empfänger mit einer Differenz von -1 in den IP-Paketnummern auseinander liegen. Es ist also zu prüfen, welchen Grund diese Ereignisse haben könnten. Der Kunde wird befragt, es kommen folgende Auskünfte: ■

■

Im Campus-LAN der Hauptstelle (woher die IP-Pakete stammen) kann die Verdrehung der IP-Pakete im Falle von RTP und RTCP nicht stattgefunden haben, da der VoIP-Endpunkt ein Router ist, der seine Daten unmittelbar an den WAN-Provider übergibt. Im WAN des Providers kann – angeblich – auch kein gegenseitiges Überholen der IP-Pakete stattfinden, da es sich – angeblich – um ein reines FrameRelay-Netzwerk handelt, das mit reinen Punkt-zu-Punkt-Verbindungen die Außenpunkte des WANs (die Zugangs-Router bzw. Edge-Gateways) direkt verbindet.

Da die Angaben des Kunden, was dessen Campus-LAN anbetrifft, nachprüfbar sind und stimmen, stellt sich die Frage, ob die Aussage des WAN-Providers richtig sein kann, dass ein direkter Frame-Relay-Tunnel tatsächlich Ende-zuEnde arbeitet. Die Befunde deuten nämlich darauf hin, dass der Frame-Relay-Tunnel nicht von Ende-zu-Ende arbeitet, sondern zwischendurch unterbrochen wird durch eine innen liegende IP-Routing-Struktur. Sollte sich dieser Verdacht verfestigen, so hätte dies gravierende Folgen: ■

■

■

Es läge Vertragsbruch vor, da die Vereinbarung zwischen Kunde und WAN-Provider eindeutig eine direkte Punkt-zu-Punkt-Verbindung per Frame-Relay vorsieht. Eine mehr oder weniger heimliche, vermaschte IP-Stuktur innerhalb des Frame-Relay-Netzwerkes könnte sehr wohl zu tun haben mit den Auffälligkeiten und Fehlern, die im VoIP-Bereich gesucht werden. Es war also die Frage: Würde sich der Verdacht erhärten? Mehr dazu weiter unten im Fortgang der Analyse.

>>> NEW TECH

629

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Abbildung 15.25: Event-Log: Es ergibt sich der klare Hinweis, dass IP-Pakete in verdrehter Reihenfolge am Messpunkt eintreffen (Beispiel 1) – was zu erheblichen Schlussfolgerungen führt.

Abbildung 15.26: Event-Log: Es ergibt sich der klare Hinweis, dass IP-Pakete in verdrehter Reihenfolge am Messpunkt eintreffen (Beispiel 2). Ein Differenzwert von -11 könnte auf einen Zählfehler von Windows XP-Clients hindeuten.

630

>>> NEW TECH

Analyse in Castrop-Rauxel (Niederlassung)

15.3.7 Untersuchung der TTL-Werte Es war bereits anlässlich der in verdrehter Reihenfolge aus dem WAN eintreffenden IP-Pakete der Verdacht aufgekommen, dass zwischen Hauptstelle und Niederlassung nicht ein direkter, ununterbrochener Frame-Relay-Tunnel arbeitet, sondern dass es innerhalb der Frame-Relay-Wolke eine IP-Routing-Struktur gibt, die es laut Vertrag zwischen WAN-Provider und Kunden gar nicht geben darf. Da dieser Verdacht sowohl technisch als auch juristisch brisant ist, muss er bis zum Beweis erhärtet oder eben widerlegt werden. Die entsprechende Untersuchung wurde in der Unternehmenszentrale durchgeführt, da die dortigen Messdaten schon wegen der ungleich höheren Datenmenge mehr Aussicht auf Erfolg boten. Siehe daher: Abschnitt D: »Analyse in der Unternehmenszentrale«.

15.3.8 RTP-Paketverluste und RTCP-Meldungen dazu Sind erst einmal Hinweise auf schlechte Sprachqualität bei den VoIP-Verbindungen gegeben, sind nicht (bzw. nicht nur) Paketverluste als solches interessant, vielmehr stellt sich die Frage, ob sich Hinweise auf etwaige Ursachen von Paketverlusten gewinnen lassen. Es ist nämlich durchaus nicht so, als sei man in jedem Falle Paketverlusten in WAN-Wolken hilflos ausgesetzt. Natürlich ist es so, dass man dem WAN-Provider nicht direkt auf die Finger sehen kann, weil man keinen Zugriff auf dessen Anlagen erhält. Aber es ist doch in vielen Fällen immer wieder mal möglich, aus dem Kommunikationsverhalten klare Indizien zu gewinnen über das, was da geschieht. Voraussetzung hierfür ist eine über Stunden oder Tage laufende Beobachtung des Verkehrs bzw. die über solch lange Zeiträume laufende Messung; weiterhin müssen die auf Festplatte gesicherten Messdaten auf bestimmte Phänomene hin untersucht werden. Im Falle der VoIP-Verbindungen wird zunächst wie folgt verfahren: ■

■ ■

Die RTCP-Meldungen werden ausgewertet, da die VoIP-Endpunkte selber Auskunft geben über fehlende Pakete (die sie hätten erhalten müssen, die sie aber nicht erhalten haben). Die RTP-Pakete müssen ihrerseits daraufhin untersucht werden, ob Pakete fehlen. Dies ist möglich, da RTP über eigene Paketzähler verfügt. Im Abgleich der RTP-Verlust-Analyse sowie der RTCP-Verlustmeldungen lässt sich erkennen, wo vermutlich die Pakete verloren gegangen sind: in der WAN-Wolke oder diesseits bzw. jenseits der WAN-Wolke.

Sodann ist zu untersuchen, ob andere Applikationen (insbesondere solche, die im Gegensatz zu den UDP-gestützten Protokollen RTP und RTCP über das verbindungsorientierte TCP arbeiten) ebenfalls unter Paketverlusten zu leiden

>>> NEW TECH

631

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

haben bzw. insgesamt unter Fehlern, die sich plausibel auf Fehler im WAN zurückführen lassen: ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Paketverluste Werte für die TCP Window Size von 536, 576 und ähnlich Werte für die TCP Maximum Segment Size von 536, 576 und ähnlich Verdrehungen in der Reihenfolge von IP-Paketen Wechselnde TTL-Werte bei IP-Paketen des jeweils selben Absenders Alle diese Erscheinungen lassen sich i.d.R. auf Vorkommnisse im WAN zurückführen: Paketverluste: Überlast, Leitungsausfall, Router-Ausfall, Konfig-Fehler TCP WinSize, TCP-MSS: Black Hole Router mit MTU-Problemen verdrehte IP-Pakete, wechselnde TTL-Werte: verschiedene und wechselnde WAN-Routen zwischen zwei Endpunkten Im vorliegenden Beispiel wird zunächst nach Hinweisen in den Protokollen RTP und RTCP gesucht.

Abbildung 15.27: RTCP-Meldungen mit der Mitteilung von RTP-Paketverlusten (aus Sicht des RTCPAbsenders in dessen Rolle als RTP-Empfänger)

Tatsächlich lassen sich RTCP-Meldungen der VoIP-Endpunkte über Paketverluste nachweisen. In nicht wenigen Fällen tauchen diese Meldungen zeitgleich mit TCP Retransmissions und IP-Paketdrehern auf. Sofern man nicht geneigt ist, dieses Zusammentreffen als reinen Zufall abzutun, ergibt sich der Verdacht, dass die RTP-Paketverluste denselben Ursachen zuzuordnen sein dürften wie die IP-Paketdreher und wie TCP-Paketverluste, deren Folge wiederum die TCP-ReTx waren (siehe Abbildung 15.28).

632

>>> NEW TECH

Analyse in Castrop-Rauxel (Niederlassung)

Abbildung 15.28: Zur selben Zeit, da via RTCP Meldung über RTP-Paketverluste gemacht wird, sind TCP-ReTx und IP-Paketdreher festzustellen – Zufall?

Nach gelegentlichen Paketverlusten zu Beginn der Messung (siehe Abbildung 15.29 und Abbildung 15.30) treten gegen Ende der Messung plötzlich massiv Paketverluste auf (siehe Abbildung 15.31). Da immer wieder parallel dazu auch in anderen Protokollen bzw. Anwendungsdialogen Pakete verloren gehen und da die oben skizzierten Nachweise auf Ebene von TCP und IP erbracht werden können, wird immer klarer: die teilweise dramatischen RTP-Paketverluste gehen aufs Konto der WAN-Verbindungen. Dies ergibt sich später auch im Abgleich mit den Messdaten, die zeitgleich in der Hauptstelle aufgezeichnet wurden. Da die besagten IP- und TCP-Effekte eindeutige Hinweise (besser Nachweise) von Fehlern des WAN-Providers sind, kann nun an diesen Lieferanten mit klaren Forderungen herangetreten werden: Entweder muss das monatlich fällige Entgelt für die WAN-Verbindungen vermindert werden, weil die zugesicherten Leistungen nicht vollständig erbracht wurden (Bitrate, Verfügbarkeit, Laufzeiten, Laufzeitschwankungen) oder aber die Leistungen müssen den zugesicherten Umfang erreichen – was Nachbesserungen unausweichlich macht. Es sei wie immer darauf hingewiesen: Nachweise dieser Art sind zurzeit mit anderen Werkzeugen als TraceMagic nicht oder kaum möglich. Wir hatten oben schon gesehen, dass die schönen Bilder des Observer-Analyzers zwar die starken zeitlichen Schwankungen dargestellt, aber keinen Hinweis auf Ursachen gegeben haben.

>>> NEW TECH

633

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Wenn wir nunmehr jedoch den Nachweis haben, dass im WAN Pakete verloren gehen und dass sich bestimmte Muster dabei herausbilden lassen, so dürfen bzw. müssen wir inzwischen von folgendem Szenario ausgehen: ■ ■

■

■

■

Auf den WAN-Leitungen bzw. den angeschlossenen Frame-Relay-Knoten herrscht bisweilen Überlast. Der WAN-Provider hat, wie es bei Frame-Relay üblich ist, die Leitungskapazität in Form von Overbooking (Überbuchung) mehrfach verkauft – in der Hoffnung, dass nicht alle Kunden gleichzeitig ihre Committed Information Rate (CIR) nutzen, weil dies eben zu Staus und Verlusten führt. Bei Überlast der angeblich als Punkt-zu-Punkt-Tunnel aufgebauten FrameRelay-Verbindungen werden die Pakete über Umwege geleitet, die es laut Vertrag gar nicht geben dürfte. Bei diesen Umleitungen ereignen sich IP-Paketdreher sowie Variationen in den TTL-Werten der durchlaufenden IP-Pakete. Außerdem schwanken die Paketlaufzeiten im WAN zwischen den Endpunkten. Finden die Umschaltungen zwischen verschiedenen WAN-Routen sehr schnell und in starkem Wechsel statt, erklären sich daraus auch die RTPLaufzeitschwankungen (Effekt: Jitter).

Das alles lässt sich aus den Messdaten klar ableiten – immer unter der Bedingung, dass man ein Werkzeug hat, das diese Befunde möglich macht und das die Effekte der verschiedenen Protokolle und Schichten auch in der Gesamtschau als Ganzes und in ihren Wechselwirkungen erkennen und erklären lässt.

Abbildung 15.29: Event-Log/RTP-Paketverlust (1): Die oben im Fenster angezeigten RTCP-Meldungen der VoIP-Endpunkte weisen noch NULL RTP-Paketverluste aus. Im Fenster unten weist TraceMagic sodann den ersten RTP-Paketverlust nach: Die RTP-Sequenz 94 fehlt.

634

>>> NEW TECH

Analyse in Castrop-Rauxel (Niederlassung)

Abbildung 15.30: Event-Log/RTP-Paketverlust (2): In den unmittelbar nächsten RTCP-Meldungen weisen beide VoIP-Endpunkte RTP-Paketverluste aus: mal eine, mal fünf RTP-Sequenzen fehlen. Die eine fehlende RTP-Sequenz konnte in den Daten des aktuellen Messpunktes nachgewiesen werden; die fünf fehlenden RTP-Sequenzen sind in den Messdaten nicht nachweisbar, was besagt: Diese RTP-Pakete waren am Messpunkt noch vorhanden und müssen erst später im WAN verloren gegangen sein.

Abbildung 15.31: Event-Log/RTP-Paketverlust (3): Fehlende RTP-Pakete sind zu Beginn einer jeden Trace-Datei nicht selten, weil zum Zeitpunkt des Schreibens einer jeden Trace-Datei ein paar Pakete im Analyzer-Buffer verloren gehen. Wenn aber mittendrin Pakete fehlen, geht dies eindeutig aufs Konto von Paketverlusten im Netzwerk, hier: Siehe ab TraceDatei 21, Frame Nummer 12802. (Wegen der langen Textzeilen im Event-Log sind hier zwei Editorfenster offen und nebeneinander gelegt, um das Wesentliche darzustellen.)

>>> NEW TECH

635

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Ohne TraceMagic sind diese Befunde zurzeit entweder gar nicht oder nur mit unverhältnismäßig großem Aufwand und nur mit höchst ungewisser Aussicht auf Erfolg nachzuweisen.

15.4 Analyse in der Unternehmenszentrale Parallel zur Messung in der Niederlassung in Castrop-Rauxel war eine Messung im Hauptsitz des Unternehmens zur selben Zeit gestartet worden.

15.4.1 Der Messpunkt Der Messpunkt wurde genauso gelegt wie in Castrop-Rauxel: Der Analyzer empfing die Daten vom Mirror-Port genau des Switches, der dem WAN-Router gegenüber lag. Gespiegelt wurde der Switch-Port, der den Anschluss zum WAN-Router hatte.

15.4.2 IP-Hosts und Paketdreher Zweck der Analyse war es (nachdem die Erkenntnisse aus Castrop-Rauxel schon vorlagen), Hinweise zu gewinnen über etwaige Instabilitäten im WAN, über welches alle Außenstellen bzw. Niederlassungen angebunden waren.

Abbildung 15.32: Event_Log: H‰ufige Verdrehungen der IP_Paketreihenfolge bzw. der IP_Paketnummern (1). – In den Klammern der Differenzwert zwischen den IP Packet IDs jeweils zwei aufeinander folgender IP_Pakete desselben Absenders.

636

>>> NEW TECH

Analyse in der Unternehmenszentrale

Abbildung 15.33: Event-Log: Häufige Verdrehungen der IP-Paketreihenfolge bzw. der IP-Paketnummern (2). – Der Differenzwert von 11 weist auf eine Windows 2000/Windows XP-Eigenheit hin (siehe: Fallstudie Windows XP). Der Differenzwert von 1 weist ganz sicher auf IP-Paketdreher hin – trotz ungleicher Empfänger ist hier kaum eine andere Deutung möglich.

Schon während der TraceMagic-Analyse der Messdaten waren im Event-Log einige Symptome aufgefallen (siehe Abbildung 15.32 und Abbildung 15.33). Der Befund ist in der Tabelle der IP-Symptomnachweise (siehe Abbildung 15.34) sowie der IP-Host-Einzelnachweise ebenfalls greifbar (siehe u.a. Abbildung 15.45). Eine manuelle Durchsicht einiger Fundstellen bestätigt am Ende den Befund (hier nicht abgebildet).

15.4.3 IP-Hosts und Verdopplungen von Paketen und IDs Es zeigen sich in verblüffender Weise massive Hinweise darauf, dass IP-Pakete verdoppelt sein können, die aus dem WAN kommen und in das Campus-LAN der Unternehmenszentrale geschickt werden (siehe Abbildung 15.34). Tatsächlich zeigt sich bei Durchsicht der Fundstellen (hier nicht abgebildet), dass IP-Pakete mit WINS-Anfragen vervielfältigt auf der Leitung sind. Da es sich um die Pakete völlig unterschiedlicher IP-Hosts aus ebenfalls völlig verschiedenen IP-Subnetze handelt, ist praktisch auszuschließen, dass es sich um individuelle Fehler einzelner Endgeräte handelt. Es ist also – im Umkehrschluss – davon auszugehen, dass es sich um nachträgliche Verfälschungen bzw. nachträgliche Einwirkungen aktiver Netzwerk-Komponenten handelt. Im Verdacht stehen somit Router, die im Verkehrsweg zwischen den jeweiligen Absendern und dem Messpunkt stehen. >>> NEW TECH

637

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Da mehrfach die Router bzw. Layer-3-Switches eines bestimmten Herstellers dabei beobachtet wurden (in den Netzen verschiedener Kunden), IP-Pakete unter bestimmten Bedingungen zu vervielfältigen, scheint die im aktuellen Fall gemachte Beobachtung also nicht falsch eingeordnet, wenn die dargelegte Vermutung gehegt wird.

Abbildung 15.34: TraceMagic: IP-Auswertungstabellen mit Hinweisen darauf, wessen IP-Pakete auf dem Weg zum Messpunkt möglicherweise vervielfältigt wurden (IP Hdr.Dupl./Poss.MAC mult.Tx) bzw. wessen IP-Pakete trotz unterschiedlicher Inhalte dieselben IP-Paketnummern aufweisen (IP ID/Poss. Same ID in Diff. Pkt). Beides sind Hinweise auf Störungen des IP-Protokolls. Außerdem Hinweise, wessen IP-Pakete auf dem Weg zum Messpunkt in der Reihenfolge verdreht wurden (IP ID/Sort Error(s) (Wrap/OK/Error)).

Somit wird der Verdacht ein weiteres Mal erhärtet, dass die Anbindungen der Niederlassungen über das Provider-WAN nicht in direkten Frame-Relay-Tunneln arbeiten, sondern dass ab und an zwischendurch doch Switches und Router arbeiten, die es – laut Vertrag – eigentlich gar nicht geben dürfte. Dieser Verdacht wird durch den Nachweis wechselnder TTL-Werte noch weiter erhärtet (siehe unten).

638

>>> NEW TECH

Analyse in der Unternehmenszentrale

15.4.4 IP-Hosts und wechselnde TTL-Werte Neben IP-Paketdrehern sind wechselnde TTL-Werte der zweite entscheidende Hinweis auf wechselnde Routen in WAN-Wolken bzw. Provider-Netzen, die der Kunde als Untermieter nutzt und in die er nicht wirklich hineinsehen kann. Der Verfasser hat mit seinem Unternehmen schon oft Kunden geholfen, die den Verdacht hatten, dass die WAN-Verbindungen nicht nach Vertrag arbeiteten. Unter den Kunden befindet sich u.a. ein Bundesministerium in Bonn, das Probleme hatte mit den Verbindungen nach Berlin. Die WAN-Anbindung wurde (wird) durch einen allseits bekannten Provider gestellt, der damals schon seit Monaten abstritt, irgend etwas mit Paketverlusten etc. zu tun zu haben. Mit herkömmlichen Analyzern, die IP-Paketdreher und wechselnde TTL-Werte und dergleichen nicht nachweisen, lässt sich hier den WAN-Providern nicht beikommen. Dies hängt auch damit zusammen, dass herkömmliche Analyzer (deren Programmierer von diesen Zusammenhängen schlicht keine Kenntnis haben) zur Analyse von WAN-Fehlern in der Regel nur drei Kriterien kennen: ■ ■ ■

IP-Paketverluste, erkannt an TCP Retransmissions lange Paketlaufzeiten, erkannt an den Differenzzeiten der Pakete ICMP-Meldungen der im WAN arbeitenden Router

Das alles ist viel zu wenig, insbesondere deswegen, weil die WAN-Provider (ein Schelm, der Böses dabei denkt!) die ICMP-Meldungen ihrer Router nicht an die Kunden ausgeben, was besagt: die Router-ICMP-Pakete werden vor der Schnittstelle zum Campus-LAN der Kunden herausgefiltert. Um also nachzuweisen, dass es Instabilitäten im WAN gibt, auf die wiederum mit wechselnden Wegen reagiert wird (indem Ersatzwege geschaltet werden, wo der jeweilige Primärweg ausgefallen ist), müssen weitere Merkmale herangezogen werden: ■ ■

■

■

IP-Paketdreher, erkannt an der IP Packet ID Wechselnde TTL-Werte, erkannt in vollständiger Erfassung aller TTLWerte eines jeden IP-Teilnehmers (bei TraceMagic erfolgt hier der Totalnachweis für bis zu 65.500 IP-Hosts!), aufgeschlüsselt nach den jeweils kürzesten Wegen sowie davon abweichenden Wegen (siehe Abbildung 15.35 und Abbildung 15.45) Verminderung der annoncierten TCP Window Size in Reaktion auf MTUProbleme der WAN-Router, von denen die IP-Clients jedoch keine ICMPMeldungen erhalten (Black Hole Scenario). Interessant ist der laut RFC kleinste Werte von 536 Bytes. Verminderung der annoncierten TCP Maximum Segment Size (MSS) bei Sitzungsaufbau. Interessant ist der laut RFC kleinste Werte von 536 Bytes.

Es gibt noch einige andere Indizien, die aber nur schwer strukturierter Auswertung zugänglich sind und daher hier übergangen werden (zumal sie im Beispiel keine Rolle spielen).

>>> NEW TECH

639

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Im vorliegenden Fall zeigt die Liste der erkannten Vorfälle von Remote Route Changes und Remote Route Long Way (siehe Abbildung 15.35), dass es offenkundig auf einigen Strecken bzw. bei einigen IP-Hosts wechselnde TTL-Werte gibt, wobei in auffälliger Weise jeweils mehr Pakete über den längeren Weg laufen als über den kürzeren (3 Hops statt nur 2 Hops): ■ ■

TTL = 253 ergibt sich aus dem Ausgangswert TTL = 255 und 2 Router-Hops TTL = 252 ergibt sich aus dem Ausgangswert TTL = 255 und 3 Router-Hops

Siehe hierzu weiter unten die Einzelnachweise für einige IP-Hosts (Abbildung 15.41 bis Abbildung 15.45). Ein interessanter Fall ist bei IP = 193.102.111.254 zu beobachten (siehe unten).

Abbildung 15.35: TraceMagic: Nachweis aller IP-Adressen, deren Pakete auf dem Weg bis zum Messpunkt über verschiedene IP-Routen liefen: »Remote Route Changes« werden angenommen, wenn die TTL-Werte der IP-Pakete desselben Absenders wechseln (die Zahl der Router-Hops wechselt!) und »Remote Route Long Way« zeigt an, wie viele Pakete den unnütz langen Weg nahmen. Ist es Zufall, dass mit 193.102.x gleiche bzw. nahe beieinander liegende IP-Subnetze betroffen sind? Ist es Zufall, dass es IP-Absender trifft, deren letztes Adress-Byte gemeinsam auf .254 lautet?

640

>>> NEW TECH

Analyse in der Unternehmenszentrale

Abbildung 15.36: TraceMagic: Auswertung der bei Sitzungsaufbau ausgehandelten bzw. annoncierten TCP Maximum Segment Size. Werte von 536 können ein Indiz sein, dass die TCP-Hosts auf sog. Black Hole-Szenarien reagieren: Große Pakete gehen im WAN verloren; die Teilnehmer gehen nach und nach auf kleine Paketgrößen herunter. Der laut RFC kleinste unterstützte MSS-Wert liegt bei 536. Die Werte 512 und 576 werden bisweilen im selben Zusammenhang von abweichend arbeitenden IP-Treibern verwendet.

Ein interessanter Fall sind die wechselnden TTL-Werte beim Voice over IPTeilnehmer IP = 193.102.111.254, dessen IP-Pakete mit den folgenden TTLWerten eintreffen: ■ ■ ■

IP TTL = 253 in Paketen mit IP-UDP-RTP IP TTL = 254 in Paketen mit IP-UDP-RTCP IP TTL = 254 in Paketen mit IP-TCP-Q931

Hier scheint es sich möglicherweise weniger um Routing-Effekte im WAN zu handeln als vielmehr um eine Spezialität der als VoIP-Endpunkte agierenden Router: ■

■

Die RTP-Pakete scheinen beim jenseits des WANs stehenden Router auf der LAN-Seite generiert zu werden, woraus sich zwei Router-Hops von der Niederlassung bis zum Campus-LAN der Zentrale ergeben. Die RTCP- und Q931-Pakete scheinen auf der WAN-Seite der auswärtigen Router generiert zu werden, woraus sich nur noch ein Router-Hop von der Niederlassung bis zum Campus-LAN der Zentrale ergibt.

>>> NEW TECH

641

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Abbildung 15.37: VoIP-Teilnehmer IP = 193.102.111.254: Wechselnde TTL-Werte (1)/hier: TTL = 253 (UDP-RTP)

Abbildung 15.38: VoIP-Teilnehmer IP = 193.102.111.254: Wechselnde TTL-Werte (2)/hier: TTL = 254 (UDP-RTCP)

642

>>> NEW TECH

Analyse in der Unternehmenszentrale

Abbildung 15.39: VoIP-Teilnehmer IP = 193.102.111.254: Wechselnde TTL-Werte (3)/hier: TTL = 253 (UDP-RTP)

Abbildung 15.40: VoIP-Teilnehmer IP = 193.102.111.254: Wechselnde TTL-Werte (4)/hier: TTL = 254 (TCP-Q931)

>>> NEW TECH

643

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Eine Auskunft des Herstellers hierüber konnte der Verfasser bis zur Drucklegung dieses Buches nicht mehr einholen. Insgesamt aber wird der Befund der bisweilen wechselnden TTL-Werte dadurch nicht erschüttert, weil IP-Hosts mit TTL-Werten von 97 und 98 (siehe Abbildung 15.41) und Applikationen jenseits von Voice over IP bzw. RTP/ RTCP zeigen, dass es tatsächlich Wegewechsel im WAN gibt. Selbstverständlich muss bei solchen Befunden geprüft werden, ob die von TTLWechseln betroffenen Pakete von Absendern stammen, die zum Corporate Network des Unternehmens gehören!

Abbildung 15.41: TraceMagic: Einzelnachweis des IP-Verhaltens für den Host IP = 192.206.9.18; auffällig: Wechselnde TTL-Werte (97, 87). Da nur eine einzige MAC-Adresse ausgewiesen ist (die des WAN-Routers), ist ein Local Routing auf dem Campus-LAN als Ursache wechselnder TTL-Werte ausgeschlossen.

644

>>> NEW TECH

Analyse in der Unternehmenszentrale

Abbildung 15.42: TraceMagic: Einzelnachweis des IP-Verhaltens für den Host IP = 192.102.0.29; auffällig: Wechselnde TTL-Werte (252, 253). Da nur eine einzige MAC-Adresse ausgewiesen ist (die des WAN-Routers), ist ein Local Routing auf dem Campus-LAN als Ursache wechselnder TTL-Werte ausgeschlossen. Von 158 IP-Paketen liefen 153 den unnütz langen Weg (3 Router-Hops), nur 5 Pakete liefen über den kürzeren Weg (2 RouterHops).

Wechselnde TTL-Werte und IP-Paketdreher sind völlig irrelevant, wenn die Absender fremde Webserver sind, etwa in Südamerika oder Russland. (Diese beiden Weltengegenden werden hier aufgeführt, weil die Internetstrukturen dort noch reichlich unausgereift sind und dort bis heute viele Effekte dieser Art täglich zu beobachten sind.) Die Abbildungen der IP-Host-Einzelnachweise sind in vielerlei Hinsicht lehrreich. Die meisten Aspekte wurden weiter oben bereits dargestellt.

>>> NEW TECH

645

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Abbildung 15.43: TraceMagic: Einzelnachweis des IP-Verhaltens für den Host IP = 192.102.0.28; auffällig: Wechselnde TTL-Werte (252, 253). Da nur eine einzige MAC-Adresse ausgewiesen ist (die des WAN-Routers), ist ein Local Routing auf dem Campus-LAN als Ursache wechselnder TTL-Werte ausgeschlossen. Von 510 IP-Paketen liefen 503 den unnütz langen Weg (3 Router-Hops), nur 7 Pakete liefen über den kürzeren Weg (2 RouterHops).

Bei dem zuletzt dargestellten IP-Host mit der Adresse IP = 192.102.111.254 handelt es sich um einen der VoIP-Endpunkte. Die Masse der von ihm gesendeten IP-Pakete enthalten UDP-RTP und UDP-RTCP, nur ein paar wenige mit Q931 enthalten TCP. Im Gegensatz zu den anderen IP-Hosts, deren Einzelnachweise hier abgebildet sind, sind bei IP = 192.102.111.254 nicht nur eine, sondern zwei MAC-Adressen erkannt worden und beide stammen von WANRoutern. Das bedeutet, dass die IP-Pakete dieses Absenders über verschiedene WAN-Router ins Campus-LAN kommen – ein Vorgang, den es nach Auskunft des Kunden eigentlich gar nicht hätte geben dürfen. 646

>>> NEW TECH

Analyse in der Unternehmenszentrale

Abbildung 15.44: TraceMagic: Einzelnachweis des IP-Verhaltens für den Host IP = 192.121.0.32; auffällig: Wechselnde TTL-Werte (252, 253). Da nur eine einzige MAC-Adresse ausgewiesen ist (die des WAN-Routers), ist ein Local Routing auf dem Campus-LAN als Ursache wechselnder TTL-Werte ausgeschlossen. Von 54 IP-Paketen liefen 49 den unnütz langen Weg (3 Router-Hops), nur 5 Pakete liefen über den kürzeren Weg (2 Router-Hops).

Da jenseits dieser beiden WAN-Router das Provider-WAN arbeitet, verstärkt sich einmal mehr der Verdacht, dass da nicht alles mit rechten Dingen zugeht.

>>> NEW TECH

647

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Abbildung 15.45: TraceMagic: Einzelnachweis des IP-Verhaltens für den Host IP = 192.102.111.254; auffällig: Wechselnde TTL-Werte (252, 253). Obwohl zwei MAC-Adressen ausgewiesen sind (die zweier WAN-Router), ist ein Local Routing auf dem Campus-LAN als Ursache wechselnder TTL-Werte ausgeschlossen, da die Local-Routing-Statistik (Local Loop) nur Nullzähler aufweist. Von 15.790 IP-Paketen liefen 15.433 den unnütz langen Weg (3 Router-Hops), nur 357 Pakete liefen über den kürzeren Weg (2 Router-Hops). Gleichzeitig gibt es 3.010 Fälle, in denen eine IP-Paketnummer kleiner war als die Paketnummer des jeweils vorigen Pakets; davon sind 158 Vorkommnisse als Wrap-Around zu werten (Zählerrücksprung auf 0) und als OK=normal (weil zwar chronologisch die IPPaketnummern wechseln, aber je IP-Empfänger ein eigener Nummernkreis geführt wird); da aber die deutliche Mehrzahl der Ereignisse (2.709-mal) als fehlerhaft eingestuft wird, muss davon ausgegangen werden, dass massiv IP-Paketdreher auftraten.

648

>>> NEW TECH

Fazit der WAN-Analyse im VoIP-Umfeld

15.5 Fazit der WAN-Analyse im VoIP-Umfeld Da alles Wesentliche in den vorigen Abschnitten gesagt wurde, bleibt nur noch wenig zu bemerken. ■

■

Es wurden physikalisch-logische Defekte an Switches nachgewiesen, die jeweils in den Niederlassungen vor dem WAN-Router stehen und den VoIPVerkehr durchleiten. Diese Switches wurden ausgetauscht. Die Nachweise von Routing-Erscheinungen im WAN, die es nach Auskunft des WAN-Providers angeblich nicht gab und die es nach dem Vertrag zwischen Kunde und WAN-Provider nie hätte geben dürfen, führten schnell zu einem deutlichen Gespräch, das für einige Vertreter des WAN-Providers – so die Auskunft des Kunden – alles andere als angenehm war.

Es muss an dieser Stelle zur Effizienz der TraceMagic-Analyse noch Folgendes gesagt werden: ■

■

■ ■

Sowohl der Kunde wie auch die Hersteller der VoIP-fähigen Telefonanlagen und Router sowie der WAN-Provider hatten bereits seit einigen Wochen eigene Messungen angestellt. Diese Messungen fanden statt mit Observer, LANdecoder32, Sniffer sowie zusätzlichen, angeblich eigens für VoIP-Umgebungen entwickelten Testsystemen. Niemand war jedoch in der Lage, die fällige Diagnose zu stellen. Die hier geschilderten Befunde wurden gar nicht mal im Zuge einer regulären Messung erarbeitet, sondern im Zuge einer TraceMagic-Vorführung. In weniger als acht Stunden waren alle Kernbefunde vollständig ausgearbeitet und dokumentiert und dem Kunden auf CD-ROM übergeben.

Wer nur ansatzweise den Zeitdruck mit einrechnet, der in solchen Fällen herrscht (immerhin stehen große und teure Projekte unter erheblichem Terminzwang!), kann sich auf die üblichen Placebo-Tests mit den bekannten SpielzeugAnalyzern nicht einlassen. Es ist ja nicht das erste Mal, dass mit TraceMagic in weniger als acht Stunden vor Ort Befunde erhoben wurden, die seitens Lieferanten und Herstellern über lange Wochen nicht erbracht wurden. Es hat schon Fälle gegeben, wo mal acht, mal zwölf Monate (!!) des sinnlosen Suchens mit Sniffer und Co. beendet wurden mit einer für die bisher Tätigen demütigenden 8-Stunden-Analyse des Verfassers unter Einsatz von TraceMagic. Es geht hier nicht darum, einfach nur sich selbst zu loben und andere schlecht zu reden. Das steht dem Verfasser fern, da seiner Erfahrung nach sehr wohl die Techniker aller beteiligten Parteien in (fast) allen Fällen gut ausgebildet und gut motiviert sind. Nein, es geht um die Werkzeuge. Der beste Techniker kann nichts ausrichten, wenn sein Werkzeug ihn blind sein lässt gegenüber den tatsächlichen Ursachen und Wirkungszusammenhängen.

>>> NEW TECH

649

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

HINWEIS Es geht kein Weg an der Erkenntnis vorbei: Ohne das richtige Werkzeug ist die gute Ausbildung der Techniker oft schlicht wertlos.

Die tatsächliche Komplexität großer Netzwerke wird in den von angeblichen Marktführern verkauften LAN-Analyzern nicht ansatzweise abgebildet bzw. greifbar gemacht. Hier muss ein Umdenken stattfinden, wenn man gezielte und wirkungsvolle Vorbeugung betreiben will und wenn man im Notfall handlungsfähig sein will (bzw. sein muss).

15.6 FilterMagic: Der Franzose in Castrop-Rauxel Das VoIP-Szenario ist durchleuchtet. Dennoch bleibt noch etwas zu tun! Daher brauchen wir noch einmal Zeit für eine zusätzliche Betrachtung. Bei der Durchsicht der Ergebnisse war eine IP-Adresse aufgefallen, von welcher der Kunde sagte: Sie stamme aus einer Niederlassung in Frankreich. Was, um alles in der Welt, haben IP-Pakete eines Franzosen in der Niederlassung von Castrop-Rauxel zu suchen? In einer Niederlassung, die außer rund 20 PCClients nichts zu bieten hat? Das Ganze erscheint als Rätsel und darum muss es gelöst werden. Um insgesamt zu verstehen, was da geschieht, müssen aus 26 Trace-Dateien alle IP-Pakete herausgefiltert werden, die mit der französischen IP-Adresse zu tun haben. Hierzu wird das FilterMagic-Modul verwendet, das die in der TraceFilter-Datenbank hinterlegten und aktivierten Filterkriterien umsetzt und die Trefferpakete aus den Original-Trace-Dateien herauskopiert und in eine neu erzeugte Ergebnis-Trace-Datei schreibt. Dieser Vorgang dauerte im vorliegenden Fall etwa neun Minuten bei 1,5 Millionen LAN-Paketen insgesamt. Das ist absolut akzeptabel und zeigt, wie leicht bei einem filterfreien Capturing jederzeit nachträglich mit TraceMagic-Filtern die gewünschten Pakete isoliert werden können. Das ganze Verfahren wird ausführlich dargestellt, da hiermit die Gelegenheit besteht, die Nutzung der FilterMagic-Funktion (mit Rückgriff auf die TraceFilter-Datenbank) zu erklären. Am Ende ergibt sich Folgendes: Es gibt 211 Ethernet-Frames, welche die IP-Adresse aus Frankreich enthalten (herausgefiltert aus insgesamt rund 1,5 Millionen Paketen). Der besuchte Rechner in Castrop-Rauxel ist kein Server, sondern ein Client mit Windows 2000- oder Windows XP-Betriebssystem – wie der Besucher aus Frankreich auch.

650

>>> NEW TECH

FilterMagic: Der Franzose in Castrop-Rauxel

Beide Clients haben nichts, aber auch wirklich: gar nichts miteinander zu tun, wie der Kunde versichert. Überhaupt sollen die Rechner aus den französischen Niederlassungen nur mit den Servern der Unternehmenszentrale sprechen, nicht aber mit Client-PCs anderer deutscher Niederlassungen. Es ist schon unklar, woher der Franzosen-Rechner vom Client-PC in CastropRauxel erfahren haben kann. Als plausibler Verdacht bildet sich heraus: Da entgegen den Zusicherungen des WAN-Providers doch IP-Broadcasts über das WAN verbreitet werden (das sollte eigentlich an den Routern unterbunden werden!), muss als möglich erscheinen, dass NetBIOS-Broadcasts des Rechners aus Castrop-Rauxel irgendwann früher einmal bis nach Frankreich geroutet worden waren – wo wiederum die dortigen Windows-Rechner begierig gelernt haben, wen es sonst noch so gibt. Und da Windows-Rechner im NetBIOSUmfeld die Pflicht haben, alle bekannten NetBIOS-Namen auf Eindeutigkeit und Einmaligkeit hin zu verifizieren, bleibt ihnen im Zweifel gar nichts anderes übrig, als die entsprechenden Rechner direkt zu befragen, wer sie sind, was sie so tun und wen sie sonst noch so kennen. Das wirklich Interessante am ganzen Szenario ist, dass hier zwei Windows 2000- bzw. Windows XP-Rechner, die nun eigentlich vom alten NetBIOS-Virus frei sein sollten, weiterhin die Mimik des alten Verhaltens entfalten. Es scheint die Befürchtung berechtigt zu erscheinen, dass der bislang berühmtberüchtigte Querverkehr zwischen den Windows-Clients auch in einer homogenen Windows 2000-/Windows XP-Umgebung nicht notwendig vorbei sein müsste. Hier wird man in der Zukunft noch genau hinsehen müssen. Für den Kunden hat dies – wenigstens vorübergehend – die Konsequenz, dass die Verkehrslast bzw. Verbindungs-Matrix im WAN nicht mehr vollständig sicher vorhergesehen werden kann: Es muss damit gerechnet werden, dass in gewissem Umfang Teile der zur Verfügung stehenden Bit-Rate für solche Direktanfragen der Clients untereinander verschwendet werden. Wie immer sind selbstverständlich die hier sichtbaren Domain-Namen über das TraceAnon-Modul ausgetauscht worden, um keinen Rückschluss auf den Kunden zu ermöglich.

Abbildung 15.46: Event-Log: Es waren sowohl Kerberos-Dialoge aufgefallen wie auch die IP-Adresse 158.206.x.x, die aus Frankreich kommt und in Castrop-Rauxel nichts zu suchen hat. Dies löst weitere Untersuchen aus (im Folgenden: FilterMagic bzw. TraceFilter).

>>> NEW TECH

651

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Abbildung 15.47: TraceMagic/TraceMenu: Es wird die Funktion FilterMagic angewählt (siehe folgende Abbildung).

Abbildung 15.48: TraceMagic/FilterMagic: Bislang ist kein tauglicher Filter definiert. Daher wird die TraceFilter-Datenbank mit Mausklick auf die Schaltfläche mit dem Trichter-Symbol (rechts) aufgerufen.

652

>>> NEW TECH

FilterMagic: Der Franzose in Castrop-Rauxel

Abbildung 15.49: TraceMagic/TraceFilter: Da bislang kein geeigneter Filter für das Vorhaben besteht, muss ein neuer Filter erzeugt werden (siehe nächste Abbildung). Jeder Filterdatensatz kann kommentiert (Textfelder rechts) und einem TraceAlias zugeordnet werden (Mitte links: der aktuelle TraceAlias ist Voice over IP). Ein TraceAlias ist ein beliebiges Ordnungskriterium (Kunde, Subnetz, Problemstellung).

Abbildung 15.50: TraceMagic/TraceFilter: Es wird ein neuer Datensatz in der TraceFilter-Datenbank erzeugt. Entsprechend dem aktuellen Zweck erhält der Eintrag den Namen »Franzose IP=158.206.x.x«. Sodann müssen die Filterkriterien noch festgelegt werden (siehe übernächste Abbildung). >>> NEW TECH

653

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Abbildung 15.51: TraceMagic/TraceFilter: Beim Anlegen eines neuen Datensatzes in der TraceFilterDatenbank wird automatisch gefragt, ob der neue Filterdatensatz dem aktuellen TraceAlias zugeordnet werden soll. Zweck ist die Möglichkeit, alle Filter abzufragen, die einem bestimmten TraceAlias zugeordnet sind.

Abbildung 15.52: TraceMagic/TraceFilter: Es wird von allen Möglichkeiten nur eine gebraucht: Die Definition einer IP-Adresse. In diesem Falle (wie bei MAC-Adressen auch) reicht es, nur die ersten Bytes der Adresse(n) zu definieren, was einer Subnetzadresse gleichkommt statt nur einer einzigen Host-Adresse. Somit werden alle Pakete als Treffer gewertet, deren IP-Adressen aus dem Subnetz 158.206.x.x (= Frankreich) kommen. Es könnten – theoretisch – auch noch die Verkehrsrichtungen eingeschränkt werden (nur Rx, nur Tx), oder es könnte von Include umgestellt werden auf Exclude.

654

>>> NEW TECH

FilterMagic: Der Franzose in Castrop-Rauxel

Abbildung 15.53: TraceMagic/TraceFilter: Jetzt noch eine kurze Erklärung in das Textfeld rechts schreiben und alle anderen Filterdatensätze deaktivieren (es könnten bis zu acht Filterdatensätze kombiniert werden). Danach zum Schluss den Filterhauptschalter oben rechts auf JA setzen.

Abbildung 15.54: TraceMagic/FilterMagic: Jetzt ist der gewünschte Filter vorhanden und aktiviert. Es kann über Start das Filtern der Original-Traces beginnen. Mit Mausklick auf Start kommen noch einige Abfragen (siehe folgende Abbildungen), bevor es tatsächlich los geht.

>>> NEW TECH

655

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Abbildung 15.55: TraceMagic/Vorgangs-Titel: Der Anwender wird aufgefordert, für den Eintrag in der TraceHistory-Datenbank einen Titel passend zum Zweck einzugeben.

Abbildung 15.56: TraceMagic/Behandlung der IP-Adressen während des Filterprozesses: Wenn damit zu rechnen wäre, dass die IP-Adresse(n), auf die der Filter abzielt, auch eine Rolle spielen bei DHCP, WINS, DNS etc, so wäre die Option »0 = Keine Einschränkung« zu wählen. Hier ist Gründlichkeit gegen Geschwindigkeit abzuwägen.

Abbildung 15.57: Sind die Filter initialisiert (eingerichtet), kommt eine Bestätigung, mit welcher die Zahl der aktiven Filter angegeben wird.

656

>>> NEW TECH

FilterMagic: Der Franzose in Castrop-Rauxel

Abbildung 15.58: TraceMagic/Trace-Treffer: Es ist unbedingt wichtig, beim Filtervorgang die Trefferpakete in eine neue Trace-Datei zu schreiben: Dies ist ja gerade Sinn des Vorgangs.

Abbildung 15.59: TraceMagic/Text-Decodes: Um über die Filtertreffer ggf. schnelle Übersicht erlangen zu können, kann das Erzeugen von einfachen Text-Decodes eingestellt werden (ist sonst regelmäßig mit NEIN zu beantworten).

>>> NEW TECH

657

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Abbildung 15.60: TraceMagic/Start: Letzte Abfrage, ob der Vorgang mit den aktuellen Einstellungen tatsächlich gestartet werden soll

Abbildung 15.61: TraceMagic/Projektverzeichnis mit den Ergebnisdaten und Report-Dateien: Unmittelbar nach dem Start zeigt die Meldung, wo auf der Festplatte die Ergebnisdaten abgelegt werden.

658

>>> NEW TECH

FilterMagic: Der Franzose in Castrop-Rauxel

Abbildung 15.62: TraceMagic/TraceHistory: Jeder Vorgang endet mit dem Aufruf der TraceHistory: TraceVerarbeitung Nummer 533; Titel des Vorgangs; TraceMagic-Anwender; Analyzer-Typ; Trace-Verzeichnis; Liste der verarbeiteten Trace-Dateien (Liste links) sowie der Ergebnis-Dateien (Liste rechts)

Abbildung 15.63: TraceMagic/TraceHistory: Das Memo-Feld der TraceHistory enthält immer einen kurzen Nachweis der Trace-Verarbeitung sowie die eingestellten Filterkriterien.

>>> NEW TECH

659

Kapitel 15 • OSI-Schicht 7: Fallstudie Voice over IP

Abbildung 15.64: Ergebnis von FilterMagic (1): Aus rund 1,5 Millionen Ethernet-Frames wurden 211 IP-Pakete isoliert, welche die IP-Adresse 158.206.x.x enthalten.

660

>>> NEW TECH

FilterMagic: Der Franzose in Castrop-Rauxel

Abbildung 15.65: Ergebnis von FilterMagic (2): Der französische Besucher ist wie der lokale WindowsClient ein Windows 2000- oder Windows XP-Rechner, der sich via TCP-Port 445 und SMB sowie TCP-Port 88 bzw. Kerberos wie alte Windows 9x/Windows NT4-Clients verhält: Per Direktkontakt Peer-to-Peer (von Client zu Client) wird abgefragt: Wer bist du? Welche Rechner kennst du denn so in diesem Netzwerk? (Die Kommentare »Checksum Error« ergeben sich aus einem Austausch der IP-Adressen zum Zwecke der Anonymisierung der Messdaten.)

>>> NEW TECH

661

Kapitel 16 Schlusswort: Zeit ist Geld Zu guter Letzt, nachdem vom Physical Layer bis zum Application Layer Nachweismethoden und Zusammenhänge in diesem Buch gründlich beleuchtet wurden, soll zum Schluss gefragt werden: ■ ■ ■ ■

Was hilft das? Hilft mir das, Geld zu sparen? Hilft mir das, Kunden schneller und preiswerter zu bedienen? Hilft mir das, meine Reaktionszeiten zu verkürzen und Verluste zu mindern?

16.1 Zeitnah und online Im Januar 2003 schickte ein TraceMagic-Reseller einen Trace an den Verfasser mit der dringenden Bitte um schnelle Hilfe. Nur eine Stunde später stand auf einer mittels Passwort geschützten Web-Seite ein vollständiges, in sich geschlossenes, voll indiziertes HTML-Projekt mit den gesammelten Ergebnissen der Analyse: Physical Layer bis Application Layer, alle Auffälligkeiten und Fehler. Der Kunde konnte kaum eine Stunde nach Beendigung der Messung die Ergebnisse auf seinem Bildschirm betrachten: Leicht verständlich, auch ohne Vorkenntnisse. Unter der Vorausetzung, dass sich Messdaten, mit WinZip gepackt, im Volumen auf bis zu ca. 10 MByte beschränken, sind in der Tat Reaktionszeiten in der Ferndiagnose möglich, und sind Präsentationsformen möglich, die bisher nicht bekannt waren.

16.2 Analyse-Ergebnis: HTML-Projekt Die folgenden Bilder zeigen ein fast vollständig automatisch erzeugtes HTMLProjekt, das praktisch alle Ergebnisse umfasst, die TraceMagic erarbeiten kann. Die HTML-Tabellen werden aus den Ergebnisdatenbanken heraus erzeugt, die Ablaufnachweise, farblich gegliedert, wurden aus dem Event-Log abgeleitet. Dieserart leicht nachvollziehbar, können auch komplizierte Netzwerkfehler dem Halblaien schnell zugänglich gemacht werden, zumal auch hier der Zugriff auf die Knowledgebase gegeben ist (über HTML-Links).

>>> NEW TECH

663

Kapitel 16 • Schlusswort: Zeit ist Geld

16.3 WWW: Projekt-Steuerung Auf einen passwortgeschützten Web-Server gelegt, werden solche HTMLProjekte ein mächtiges Mittel, um Migrationsprojekte, Störfallmaßnahmen etc. zwischen mehreren Partnern leicht und umfangreich zu steuern. Es kann nicht angehen, dass man Wochen wartet, bis man alle Lieferanten, Systemhäuser, Dienstleister und Hausabteilungen zu den beliebten Elefantenrunden beisammen hat. Es ist einfacher, eine klare Faktenbasis zu schaffen über das, was noch zu tun ist, und die Nachweise allen zur Verfügung zu stellen. Diese Art des Projektmanagements ist lange schon üblich, nur wurde es bisher kaum im Bereich der LAN-Analyse und LAN-Migration angewendet. Hierfür bietet die HTML-Ausgabe von TraceMagic eine mächtige Hilfe: ■ ■ ■ ■ ■

Zeit und Geld sparen Wissen verfügbar machen Reaktionszeiten verkürzen Dienstleistungen verbessern zielgenau handeln

In Zeiten, da Personal bzw. Arbeitszeit zur teuersten Ressource heran gewachsen sind, muss intelligentes Information Management helfen, die Kosten zu senken, indem Reisezeiten möglichst vermieden werden. Dass die allseits bekannten LAN-Analyzer hierzu nicht den geringsten Ansatz bieten, zeigt – aus Sicht des Verfassers – einmal mehr die völlige Weltfremdheit ihrer Hersteller. Ohne Rücksicht auf die wirtschaftlichen und insbesondere zeitlichen Belange können derlei Werkzeuge kaum hoffen, noch länger Akzeptanz zu finden.

16.4 TraceMagic: LAN-WAN Information Management Insoweit hätten wir zum Schluss einen weiten Bogen gespannt von Bits-undBytes auf der Leitung bis zur übergreifenden Organisation umfangreicher LANWAN-Projekte. Dass das eine mit dem anderen eng verzahnt ist, wurde leider in der Vergangenheit nicht immer genügend wahrgenommen: Viel zu oft wurde mutig migriert, ohne zunächst dafür gesorgt zu haben, dass die bestehende Landschaft frei von Fehlern war. Migrationsfähigkeit hängt auch mit Fehlerfreiheit zusammen und Abnahmefähigkeit: Beides verlangt die Fähigkeit, schnell klare und umfassende sowie zweifelsfreie Befunde beschaffen und diese möglichst schnell und einfach verteilen zu können. Alles dies ist möglich, und alles dies hilft, Zeit und Geld zu sparen.

664

>>> NEW TECH

TraceMagic: LAN-WAN Information Management

Abbildung 16.1: Das Hauptmenü des vollautomatisch erzeugten HTML-Projekts, welches (fast) alle Ergebnisse der TraceMagic/SpiderMagic-Auswertung umfasst

Abbildung 16.2: TraceMagic/HTML-Ausgabe: Tabelle der TCP/IP-Befunde. Die Protokoll-EreignisKennungen (Protocol Event Codes, links) sind per HTML-Link mit der KnowledgebaseSeite verknüpft. >>> NEW TECH

665

Kapitel 16 • Schlusswort: Zeit ist Geld

Abbildung 16.3: TraceMagic/HTML-Ausgabe: Tabelle der TCP/IP-Befunde. Hier: Nachweis des TCP-Sitzungs-Verhaltens sowie TCP-Paket-Drehern

Abbildung 16.4: TraceMagic/HTML-Ausgabe: Tabelle der TCP-Port-Statistik bzw. der Applikationsanalyse. Auch hier sind die Angaben per HTML-Link mit der Knowledgebase-Seite verknüpft.

666

>>> NEW TECH

TraceMagic: LAN-WAN Information Management

Abbildung 16.5: TraceMagic/HTML-Ausgabe: Tabelle der IP-Host-Befunde. Ein Mausklick auf die Zähler der Protokolle IP, TCP und ICMP öffnet weitere Tabellen mit den Einzelnachweisen dieser Protokolle. Der HTML-Link [i] ganz links führt zum Einzelnachweis des jeweiligen IPHosts. Die Sternchen (*) rechts weisen auf Fehler und Auffälligkeiten hin.

Abbildung 16.6: TraceMagic/HTML-Ausgabe: Das Event-Log ist im HTML-Format automatisch farbig: Verschiedene Protokolle, Fehler und Ereignisse werden mit getrennten Farben markiert. Dadurch ist bei schneller Durchsicht eine größtmögliche Übersicht gegeben. Die Farbzuweisungen bleiben jedem Anwender selbst überlassen.

>>> NEW TECH

667

Kapitel 16 • Schlusswort: Zeit ist Geld

Abbildung 16.7: TraceMagic/HTML-Ausgabe: Tabelle der TCP/IP-Befunde. Die Knowledgebase ist von vielen der verschiedenen HTML-Seiten direkt erreichbar, um kontextsensitive Hilfe zu geben. Wie im Hauptprogramm auch, kann die Wissendatenbank neben allgemeinen Hinweisen auch die Einträge des Anwenders oder beliebiger Dritter enthalten.

16.5 Ausblick Der Verfasser ist mit seinem Unternehmen Synapse:Networks strikt bemüht, nicht nur rein akademisch die Nachweismethoden für LAN-WAN-Fehler zu verfeinern. Er ist zudem stets darauf bedacht, die Effizienz zu steigern und die Reaktionszeiten zu vermindern, gleichzeitig die Zuverlässigkeit einer LAN/WAN-Analyse aus Sicht des Kunden mit der hinreichenden Glaubwürdigkeit auszustatten. Es kann nicht sein, dass massenhaft auf LAN-Analyse verzichtet wird, weil die Aussicht auf zuverlässige Befunde zu ungewiss ist und die zu veranschlagenden Arbeitszeiten und Honorare kaum kalkulierbar sind. Vom Stand des Jahres 2000 (Erstausgabe des Networker's Guide) bis zum Erscheinen dieses Buches in 2003 wurde ein riesiger Schritt nach vorne gemacht: ■ ■

668

Handarbeit und Stichprobenprinzip wurden durch zuverlässige Maschinenarbeit ersetzt. Lückenhafte, manuell gefertigte Berichte wurden weitgehend durch automatisch erzeugte Befunde ersetzt: Berichtsdateien, Tabellen, Datenbanken, HTML-Projekte geben vertikal (vom Vorstand bis zum Techniker) wie auch horizontal (vom Kunden bis zum Dienstleister und Lieferanten) schnell und weitgehend lückenlos die Fakten bekannt.

>>> NEW TECH

Ausblick

■ ■ ■ ■

Teure Arbeitszeit wurde ersetzt durch preiswerte (und vor allem: verfügbare!) Maschinenlaufzeit. Wir werden alle gemeinsam diesen Weg weiter zu gehen haben, da die Verfügbarkeitsanforderungen der Unternhmen keine andere Wahl lassen, und da die dramatisch steigenden Datenvolumina für die Zukunft jede Form der primär auf Handarbeit gestützten Analyse kategorisch ausschließen.

So dürfen Verlag und Verfasser auch dieses Buch beschließen mit dem Ausblick auf die nächste Auflage. Es wird wieder Neues zu berichten geben, und es werden wieder Anstrengungen nötig sein, um täglich neu das Datennetz zu retten.

>>> NEW TECH

669

Anhang Internetadressen von Herstellern und Produkten URL

Hersteller, Produkt

www.acterna.com

Acterna (Wavetec-Wandel-Goltermann): Domino

www.agilent.com

Agilent (Hewlett-Packard): Network Analyzer

www.datakom-gmbh.de

Datakom GmbH: NetVCR

www.ethereal.com

Ethereal: Ethereal

www.ntop.org

NTop.org: Ntop

www.finisar.com

Finisar (Shomiti): THG, Surveyor

www.flukenetworks.com

Fluke: NetTool, NetInspector

www.networkinstruments.com

Network Instruments: Observer

www.niksun.com

Niksun: NetVCR

www.sniffer.com

NAI: Sniffer

www.synapse.de

Synapse:Networks: TraceMagic

www.tcpdump.org

TcpDump.Org: TcpDump

www.tracemagic.net

Synapse:Networks: TraceMagic

www.trafficmonitor.de

Böer Software: Traffic Monitor

www.triticom.com

Triticom: LANdecoder32

www.wildpackets.com

WildPackets: EtherPeek NX, TokenPeek

Internetadressen mit weiteren Informationen: http://www.alvitec.ch/hotsauce/welcome.html http://www.iana.org/numbers.html http://msdn.microsoft.com/archive/default.asp?url=/ARCHIVE/en-us/dnarwnet/ html/msdn_bonnet.asp http://www.synapse.de/tracemagic/tm.power.htm

>>> NEW TECH

671

Stichwortverzeichnis

A ACK – TCP ACKs, ausstehende 309 – TCP ACKs, die keine sind 312 Acterna siehe Hersteller Address Resolution Protocol siehe ARP Adresse – Adressauflösung bei TCP/IP 242 – ARP 229 – Broadcast-Adresse 246 – DNS 229 – Einser-Broadcast-Adresse 249 – IP Address 244 – IP Subnet Mask ist falsch 282 – IP-Adresse im falschen Subnet 282 – IP-Broadcast-Adresse ist falsch 282 – MAC Address 243 – MAC-Adresse, doppelte 244 Adressen – Filter auf IP-Adressen 279 – IP-Adressen, doppelte 281 ADS siehe Protokolle Agilent siehe Hersteller Analysatoren – LANdecoder32 283 – LANreport 283 – Observer 283 – Sniffer 283 Analyse – Abnahmeprotokolle 115 – Activity-Tools 108 – Applikations-Analyse 54, 393f., 503, 521 – Arbeitsteilung 89, 107 – Aufzeichnungszeiträume, lange 81 – Auto-Detection 399, 402 – Automation 108, 113 – Berichtswesen 89 – betriebliche Abläufe 111 >>> NEW TECH

– Capturing 100 – Client/Server-Analyse 522 – Dateizugriffe, Nachweis aller 579, 591 – Datenmengen, große 81, 112 – Diagnoseschritte 54 – Effizienz 89 – Einsparungen 116 – Erdungsfehler 174 – Erfolgskontrolle 116 – Ergebnisdaten, Verteilung 110, 663 – Ergebnisumsetzung 89 – Ergebnisweitergabe 89, 110 – Fehler, spontane 82 – Ferndiagnose 663 – File Handle 129, 579 – File Reconstruction 521 – Filter 73 – Filter-Datenbank 86 – Gigabit 27, 169 – History-Datenbank 86 – HTTP Proxy Ports 399 – HTTP-Analyse 399 – ICMP 254 – IP 263, 283 – IP Host Events 538, 556, 601 – IP-Analyse 44, 46, 328, 503 – Kostenrechnung 30, 116 – Laufzeitschwankungen 613 – Leistungsnachweise 115 – Lösungswissen 87 – Mirror Port 197 – NCP-Analyse 397 – Negativ-Nachweis 85, 112, 115, 119 – neue Wege 103 – Offline-Analyse 37, 81 – online 663 – Online-Analyse 37, 81 – Planbarkeit 116

673

Stichwortverzeichnis

– – – –

Port Auto-Detection 399, 402 Port Statistics 538, 549 Port-Nachweis je Server 513 Positiv-Nachweis 85, 112, 115, 119 – Qualifizierung 61f. – Quantifizierung 61f. – rc.files 521 – Reports 87, 112, 123 – RMON 108 – Rüstscheine 116 – Script Command Tracking 521 – Script Follow-Up 521 – SMB-Analyse 397, 566, 574 – SMB-Statistiken 538 – SNMP 108 – Statistiken 81 – Stichproben 41, 104, 113 – Stichproben siehe Filter – TCP 286, 299, 315 – TCP Port Statistics 538, 549 – TCP/IP-Analyse 28, 120f., 328, 394, 499, 520, 540 – TCP/IP-Statistiken 538 – TCP-Analyse 342, 403, 429, 503, 525 – UDP 316 – UDP Port Statistics 538, 549 – Uhrzeit der Fehlerursache 39 – Umgebungswissen 87 – Verifikations-Analyse 84 – Vorgehensweise 430 – Wahl der Messpunkte 517 – Wandel 103 – Zeit ist Geld 663 – Zeitangabe 82 – Zeitfenster 38, 81, 112 – zeitnah 663 – Zugriffstabellen 579, 591 – Zyklus 114 – Siehe: Dateinamen – Siehe: Filter – Siehe: Messpunkte Analyse-Produkte, siehe Hersteller Analyse-Reports, siehe Analyse, Reports Analyzer-Hersteller – Siehe: Hersteller – Siehe: US-Hersteller

674

ANSI siehe Zeichensätze Antwortzeiten – lange 55, 57f., 368, 371, 381f., 459 – Laufzeitschwankungen 613, 634 – Siehe: File Services – Siehe: Name Services – Siehe: Sitzung AppleTalk siehe Protokolle Applikationen siehe TCP Applikations-Analyse 503 – Annahmestau 397 – Applikationsebene 403 – Applikations-Klassen 552 – Client/Server-Analyse 429, 522, 566 – Client/Server-Dialoge 393f., 429, 566 – Dateinamen, mutierte 430, 566 – Dateizugriffe, Nachweis aller 579, 591 – DESKTOP.INI 462, 570 – Fehlzugriff 574 – File Handle 579 – File Reconstruction 504, 521 – HTTP 399 Analyse 469 – NCP 397 – NiAgnt32.exe 572 – NiAgnt32.exe.Local 566 – NiAgnt32.exe.Manifest 566 – NTUSER.DAT 570 – Oracle 542 – Oracle TNS 399 – Pfad-Namen, mutierte 593 – Port Statistics 538 – Port-Nachweis je Server 513 – rc.files 504, 521, 568 – Reconstructed Files 568 – Script Command Tracking 521, 587 – Script Follow-Up 504, 521, 587 – Script-Abwicklung, fehlerhafte 438 – SMB 397 – SMB Denied Resources 439, 538 – SMB-Analyse 473, 566, 574 – SMB-NCP-Konflikte 460, 598 – SMB-Statistiken 538 – TCP Port Statistics 538 – TCP Sitzungsverhalten 404

>>> NEW TECH

Stichwortverzeichnis

– – – – –

TCP/IP-Statistiken 538 TCP-Analyse 403, 429 TCP-Statistiken 550 Teilnehmerebene 403 TM.SM.SpiderMagic.TABLES.~~ HTTP~~.WWW.Statistics.TXT 404, 471 – TM.SM.SpiderMagic.TABLES.~~ NCP~~.File.Handles.(Open.Close) .TXT 404, 579 – TM.SM.SpiderMagic.TABLES.~~ SMB~~.Error.Files.CSV 405 – TM.SM.SpiderMagic.TABLES.~~ SMB~~.File.Handles.(Open.Close) .TXT 405, 579 – UDP Port Statistics 538 – VoIP 401 – Zugriffstabellen 439, 468, 579, 591 – Zusammenhang mit Schichten 1-4 69, 394, 429, 503 – Zusammenhang mit Schichten 5-7 393, 429 – Siehe: Analyse Arbeitsteilung, Fehler 107 ARP 229, 232, 242, 249, 252 – Broadcasts 249 – DHCP 476 – Gratuitious ARP 476 – Hardware Destin. Address 233 – Hardware Length 232 – Hardware Source Address 233 – Hardware Type 232 – Header 232 – Operation Code 233 – Protocol Type 232 – Software Destin. Address 233 – Software Length 232 – Software Source Address 233 ASCII siehe Zeichensätze ATM 168 – ATM-Tester 42 – ATM-WAN 42 – Fehler in ATM-Netzen 42 – LAN Emulation 42, 342 – LESBUS 342 Auswertung, noch vor Ort 518 Authentication siehe Sitzung Authorization siehe Sitzung

>>> NEW TECH

B Backbone 38 BANalyzer 117 Bayerischer Rundfunk 122 Berichte siehe Analyse, Reports bi-direktional 343f. – Siehe: Sitzung Bindery siehe Protokolle, NCP Black Hole 353 BOOTP 242, 247, 279, 318 – Dialog 320 – Header 318f. – Reply 319 – Request 318 – Siehe: DHCP – Siehe: Protokolle Bootstrap Protocol siehe BOOTP BPDU siehe Spanning Tree Broadcast – Broadcast-Adresse 246 – Einser-Broadcast-Adresse 249 – IP-Broadcast-Adresse ist falsch 282 – NetBIOS 285 Browse 357 Bundesministerium 121 – Bonn-Berlin 47 C Capture Engines 171 Capturing siehe Analyse, Capturing CIFS siehe Zeichensätze Cisco – 6000-er Serie 169 – Works 108 Code Red – Siehe: TCP – Siehe: Virus Connectivity 286 Cost/Metric 275 D Data Flow Control 262 – TCP 287 – Siehe: OSI Data Link Layer siehe OSI Datei-Dienste siehe File Services Dateinamen – .{stdout} 438 – .BAT 400 675

Stichwortverzeichnis

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

– 676

.CFG 400 .CMD 400 .DMP 503 .EXE.BAT 444 .EXE.COM 444 .EXE.DIR 447 .EXE.DLL 444 .exe.Local 566 .exe.Manifest 566 .EXE.PIF 444 .INI 400 .LOG 400 .REG 400 .URL 464 >>>>.MES 438 ? .exe 449, 453 CONFIG.POL 362 DESIGNER.EXE 447 DESKTOP.INI 67, 462, 570 echo* 438 echo.dll 66 foo 448 hyph>>32.dll 436 LMHOSTS 360, 367, 478 mspfltrs.dll 465 MUP.SYS 383, 595 net* 438 NI5_FH.BAT 574, 587 NiAgnt32.exe 572 NiAgnt32.exe.Local 442, 455, 566, 598 NiAgnt32.exe.Manifest 442, 455, 566, 598 NiApMgnt.dll 600 NTUSER.DAT 68, 570 ping* 438 Platzhalter 66, 438 regedit* 439 SAPLOGIN.EXE 66 SAPLogin.exe 430 sleep* 438 SQL.INI 458 UPDATE32.DLL 387 USRMGR.EXE {..} $DATA 440 wdmaud.drw 462

– WIN>>>>.DLL 66 – WINSPOOL.DRV.DLL 66 Dateisuche siehe File Services Dateizugriffe siehe File Services DCHP, Option 01 Subnet Mask 321 DECnet 243 Default Gateway 250 DESKTOP.INI 67 DHCP 242, 245, 247, 279, 318 – Client Configuration 44 – Client Request 473 – DHCP Sever 251 – DNS Server 474 – Domain 474 – Hex-Dump 320 – IP Default Gateway 474 – IP Subnet Mask 474 – IP Subnet Mask ist falsch 282 – IP-Adressen 473 – Lease 473f. – Option 27 249 – Options/vollständige Liste 321 – Relais Agent 45 – Relay Agent 474 – Server Reply 474 – Server-Werte 45, 356 – WINS 356 – WINS Node Type 474 – WINS Server 474 DHCP siehe Protokolle DIX 249 DLC siehe Data-Link Control (Protocol) DNS 60, 229, 242, 285, 372 – %username% 387 – Anfragen, sinnlose 584 – Antwortzeit, lange 57, 368, 371, 382 – Austin, Texas, USA 371 – Dateisuche via DNS 55, 355, 360 – DHCP 474 – DNS Name 248 – DNS Server 367, 584 – DNS Server/IP Address 248 – DNS-Suche via NDS 382 – Domain-Suffix 58, 519f. – Dummy-Einträge 367 – ICMP-Meldung Port Unavailable 56, 371 – JSPNRMPTGSBSSDIR 59, 366 – Namen 355, 388, 519 >>> NEW TECH

Stichwortverzeichnis

– Raw Ethernet 285 – Runts 177, 333 – Signal Quality Error (SQE) 271 – Signal-Laufzeit 183 – TCP Window Size 350 EtherPeek siehe Hersteller, WildPackets Event-Filter, Report-Filter 531 Event-Log – Abläufe 418 – TM.HIT.FRAMES.01.~.001.LOG .TXT 404 – Zusammenhänge 404 Expertendiagnose – IP 283 – TCP 299, 315 Expertensysteme 29, 37, 90, 123 – Offline-Expertensysteme 37 – Online-Expertensysteme 37, 90 – Zeitfenster 38, 81 – Siehe: TraceMagic

– – – – –

Namensabfragen, umgekehrte 249 Namens-Mutationen 355 NetBIOS 390 Root Server 371 Script-Abwicklung via DNS 58, 382, 384 – statische Einträge 367 – Telnet-Befehle via DNS 389 – Top Level Domain 355, 363 – Wartezeiten 368, 382 – Siehe: Zeichensätze DoD-Protokolle siehe TCP/IP Domain Name Service siehe DNS Domain siehe DNS drucken, TCP Window Size Zero 51, 351 Dynamic Host Configuration Protocol siehe DHCP E EBCDIC siehe Zeichensätze EnablePMTUDiscovery 314 Ethereal siehe Hersteller Ethernet – 0x3434... 203 – 0x4343... 181, 188 – 0x434343434343 178 – 0x5555... 181 – 0x5A5A... 181 – 0xA5A5... 181 – 0xAAAA... 181 – 0xD0D0... 181, 203 – 0xD0D0D0D0D0D0 178 – Differential Manchester Codes 178 – DIX 249 – Ersatz-Bitmuster 181 – Ethernet II 249, 285 – Fast Ethernet 81 – Frame-Typ 249 – Giant-Frames 187 – Gigabit-Ethernet 27, 82, 104, 109, 169 – Inter Frame Gap 180 – Kollision 178, 333 – Längen-Fehler 333 – Late Collisions 269 – MTU 352 – Pakete siehe Frames – Prüfsumme 182 – Pseudo-Runts 181 >>> NEW TECH

F Fallstudie – Client-Server-Dialoge 394 – Provider-WAN 395 – Voice over IP 395, 609 – Windows 95-Client 395 – Windows 9x-Client 473 – Windows XP-Client 503 FDDI 168 Fehler – Adress- und Namensauflösung bei TCP/IP 242 – ARP 249 – Default Gateway 250 – DNS Name 248 – DNS Server/IP Address 248 – Empfänger nicht erreichbar 252 – IP Fragmentation fehlerhaft 252 – IP Fragmentation nicht erlaubt 252 – IP Pakete, doppelte 270 – IP Subnet Mask 246 – IP Subnet Mask ist falsch 282 – IP TTL zu gering 251 – IP-Adresse im falschen Subnet 282 – IP-Adresse, doppelte 244, 281 – IP-Broadcast-Adresse ist falsch 282 – Late Collision 269 – Local Loop 253 677

Stichwortverzeichnis

– – – – – – –

MAC Retransmissions 271 MAC-Adresse 243f. NetBIOS Name 248 RARP 249 Router 251 Router ist überlastet 252 Router, Pakete werden verworfen 251 – Routing 250 – Routing-Fehler (1) 276 – Routing-Fehler (2) 277 – Routing-Fehler (3) 277 – Sequence Number, Rücksprung 300 – Services doppelt via UDP und TCP 317 – Source-Route ist vorhanden 252 – TCP ACKs, ausstehende 309 – TCP ACKs, die keine sind 312 – TCP Data Offset (Length), Fehler 305 – TCP FIN/RST fehlen 309 – TCP Keep-Alive 310 – TCP Packets, retransmitted 300 – TCP PSH Flag, Fehler (leere Pakete) 306 – TCP SYN/RST Flags 308 – TCP Window (Size) ist eingefroren 311 – TCP Window (Size) sehr klein 311 – TCP Window (Size) wird nicht genutzt 312 – TCP, Fehler in der Offset-Folge 298 – Windows Terminal Server (WTS) 313 FIFO 69 – Siehe: Router – Siehe: Switch File Services 55, 429 – .BAT 68, 400 – .CFG 400 – .CMD 68, 400 – .INI 400 – .LOG 400 – .POL 363 – .REG 400 – ACCESS_FAILURE 369, 380 – Antwortzeiten, lange 55, 58, 459 – Client-Server-Dialoge 429 – Dateinamen, mutierte 430, 444, 566, 586

678

– Dateisuche via DNS 55, 360, 376 – Dateizugriffe, fehlerhafte 61, 448, 586 – Dateizugriffe, Nachweis aller 421, 579, 591 – DESKTOP.INI 67, 462, 570 – DNS-Suche via NDS 382 – Endlosschleife 65, 455 – Fehlzugriff 369, 376, 380, 566, 574 – File Handle 129, 376, 492, 579 – File Not Found 376 – foo 365, 448 – Get File Size 63, 459 – HTTP 399 – HTTP Proxy Ports 399 – HTTP-Analyse 469 – MCF 376, 379, 441 – Mehrfachlesen 460 – MUP.SYS 383, 595 – NCP 61, 397 – NI5_FH.BAT 574, 587 – NiAgnt32.exe 572 – NiAgnt32.exe.Local 566, 598 – NiAgnt32.exe.Manifest 566, 598 – NTUSER.DAT 68, 570 – Open File 65, 67 – Pfad-Namen, mutierte 449f., 453, 593 – Platzhalter 66 – rc.files 400, 568 – Read File 64 – Reconstructed Files 400, 568 – Script Follow-Up 587 – Script-Abwicklung, fehlerhafte 438 – Share Handle 379 – Share-Zugriff 379, 586 – SMB 61, 397 – SMB Denied Resources 538, 566 – SMB-Analyse 574 – SMB-NCP-Konflikte 460, 598 – SMB-Statistiken 538 – TM.SM.SpiderMagic.TABLES.~~ HTTP~~.WWW.Statistics.TXT 471 – TM.SM.SpiderMagic.TABLES.~~ NCP~~.File.Handles.(Open.Close) .TXT 579 – TM.SM.SpiderMagic.TABLES.~~ SMB~~.File.Handles.(Open.Close) .TXT 579 – Tree Connect 379 >>> NEW TECH

Stichwortverzeichnis

– – – – –

Tree Disconnect 379 Tree ID 379 UNC 369, 383, 586, 595 Zugriffsfehler 423 Zugriffstabellen 421, 468, 579, 591 Filter 401 – auf CIFS-Namen 75 – auf DNS-Namen 75 – auf IP-Adressen 73 – auf MAC-Adressen 73 – auf Namen 75 – auf NetBIOS-Namen 75 – auf Script-Dateien 401 – auf Textfolgen 75 – auf WINS-Namen 75 – Fehler der LAN-Analyzer 73 – FilterMagic 650 – ICMP 254 – IP-Adressen 279 – Offline-Filter 78 – Online-Filter 78 – Zeichensätze 75 Finisar siehe Hersteller Fluke siehe Hersteller Frames – Checksum 45 – CRC 45 – Current Frame 580 – defekte 40, 177, 202, 330, 333 – defekte, mit korrekter CRC 40 – doppelte 40 – Flutung 220 – Giants 187 – Längen-Fehler 333 – MAC Multiple Tx 617 – Mehrfachübertragung 50, 617 – MTU 335f., 352 – Multicast 43 – Pakete, doppelte 270 – Prüfsumme 45 – Related Frame 580 – TCP-Pakete als Multicasts 44, 615 – Unicast 43, 210 – Unicast, an Broadcast-Port 218 – Verfälschung 43, 45, 202, 209, 343, 617 – Vervielfältigung 50, 209, 212 Frame-Typ 249 Freeware siehe Hersteller

>>> NEW TECH

G Gateway, Default Gateway 250 Gigabit 27, 82, 93, 95, 97, 100, 104, 109, 169 – Antwortzeiten 359 – Capture Engine 171 – Gigabit-Ethernet 38 – Messrechner 169 – STACCer 169 – SysConnect 169 – TcpDump 172 GPL-Lizenz siehe Hersteller H Handshake – TCP 294 – Three Way Handshake 290 Hardware-Analyzer siehe LANAnalyzer Header – ARP 232 – BOOTP 318f. – ICMP 236, 297 – IP 233 – TCP 239, 287, 294 – UDP 241 Hersteller – Acterna (Wavetech Wandel Goltermann) 101 – Agilent (Hewlett-Packard) 101 – Ethereal (Ethereal) 97, 122, 401, 503 – Finisar (Surveyor) 96, 101 – Fluke (NetTool) 102 – NAI (Sniffer) 104, 222 – Network Instruments (Observer) 94 – NikSun (NetVCR) 102, 109, 113, 571 – NTOP (NTOP) 99, 108 – Synapse:Networks (TraceMagic) 100, 109 – TcpDump (TcpDump) 98, 122, 172 – Triticom (LANdecoder32) 93, 117f., 143, 527 – WildPackets (EtherPeek) 81, 95, 97, 109, 113, 213

679

Stichwortverzeichnis

Hewlett-Packard 101 – Siehe: Hersteller Hex-Dump 305 – DHCP 320 Hop Credit 259, 275 – IP TTL zu gering 251 HTTP – GET 471 – HEAD 471 – Port Auto-Detection 399 – POST 471 – TM.SM.SpiderMagic.TABLES.~~ HTTP~~.WWW.Statistics.TXT 404, 471 – Zugriffstabellen 470 – Siehe: File Services – Siehe: TCP – Siehe: TraceMagic – Siehe: WAN I ICMP 228, 235, 242, 329 – Address Format Reply 237 – Address Format Request 237 – Address Format/Subnet Mask 238 – Analyse 254 – Black Hole Router 353 – Checksum 236 – Code 236 – Code-Werte 237 – Datagram Not Processed 237 – Destination Unreachable 237, 255 – Echo Reply 237 – Echo Request 237 – Echo Request/Echo Reply 261 – Echo Request/Reply 229 – Filter 254 – Fragmentation Needed 237, 252, 260 – Grenzen 262 – Header 236, 297 – Host Unreachable 228, 237, 252, 256 – Information Reply 237 – Information Request 237 – IP Host Events 538, 556, 601 – Meldung Echo (Ping) 342

680

Fragmentation Needed (MTU) 353 Network Unreachable 605 Port Unavailable 372 Port Unavailable (DNS) 56, 371 Port Unavailable (Statistik) 542 Redirect 337 TTL = 0 339, 604 Siehe: Protokolle – Meldungen bei Umleitungen 254 – Meldungen der Router 44 – Meldungen, Übersicht 329 – Meldungen, unterdrückte 46, 50, 73, 85, 328f., 353 – Meldungen, wenn Router Pakete verwerfen 252 – Message 236 – Network Unreachable 228, 237, 255 – Operation 236 – Parameter Problem 237 – Ping 261 – Pointer Failure 238 – Port Unavailable 256, 297 – Port/Service Unavailable 237 – Protocol Unavailable 237, 256 – Redirect 229, 237, 253f., 257 – Redirect to Host 238 – Redirect to Network 238 – Redirect to Service/Host 238 – Redirect to Service/Network 238 – Router Advertisement Message 237 – Router Solicitation Message 237 – Service Unavailable 229, 297 – Source Quench 229, 237, 252, 261, 263 – Source Route Not Available 237, 252 – TCP/IP-Analyse 540 – Time Exceeded 237, 258 – Time Exceeded (Reassembly Timer Expired) 228, 238, 252 – Timestamp Reply 237 – Timestamp Request 237 – Top Talkers 538 – TraceRoute 262 – Type 236 – Type-Werte 237 ICMP siehe Protokolle

>>> NEW TECH

Stichwortverzeichnis

IMCP, Time Exceeded 262 Internet Control Message Protocol siehe ICMP Internet Protocol siehe IP Internet siehe WAN IP 233 – Analyse 263, 283 – Black Hole Router 353 – BOOTP 247 – Broadcast-Adresse 246 – Checksum 279, 340 – Corrupted Packet 330 – Default Gateway 250, 337, 474 – Destination Address 235, 279, 340 – DHCP 247 – Don't Fragment 260 – Don't Fragment (DF) 273 – Don't Fragment (DF) Bit 353 – Duplicate IP Header 331 – Empfänger nicht erreichbar 252 – Expertendiagnose 283 – Filter auf IP-Adressen 279 – Fragment ID 227, 234, 270 doppelte 270 Microsoft Lo/Hi 272 – Fragment Offset 234, 275 – Fragmentation 226, 268 – Fragmentation Flags 227, 234, 268, 273 – Fragmentierung 335f., 353 – Header 233 – Header Checksum 235 – Header Duplicated 190, 193, 615f., 637 – Header Length 228, 234, 264, 332, 342 – Hop Count 338 – Hop Credit 338 – Host Statistics 403 – Identification 234, 270 – IP Address 244 – IP Fragmentation fehlerhaft 252 – IP Fragmentation nicht erlaubt 252 – IP Host Events 538, 556, 601 – IP Subnet Mask 246, 282 – IP TTL zu gering 251 – IP und NetBIOS 284 – IP, Inc. 225 – IP-Adresse im falschen Subnet 282 – IP-Adressen 226 DHCP 473 >>> NEW TECH

– – – – – – – – – – – – – – – – – – – – – – – – – – –

– – – – – – – – – – – –

doppelte 281 Filter 73, 279 IP-Analyse 44, 46, 328, 415 IP-Broadcast-Adresse ist falsch 282 Last Fragment 275 Last/More Fragments 234 Local Loop 209, 253, 270, 335, 337, 345 Local Routing 209, 270, 335, 337, 345 MAC Broadcast 331 MAC Multicast 331 MAC Multiple Tx 331, 346, 616, 638 MAC Padding 267 May Fragment (MF) Bit 353 Multicast Address 340 Multicasts 224.0.x.x 278 Option Record Route 262 Option / Header Extension 342 Options 235 Packet Disordered 345 Packet ID 182, 333, 335, 339, 345, 628, 639 Packet ID = 0 333 Packet ID Duplicated 335 Packet ID Multiple Use 335 Packet ID, Windows-Fehler 602 Packet Ping-Pong 339 Packet Sort Error 345, 638 Padding 235 Paket-Dreher 69, 215, 345, 420, 541f., 601, 628, 632, 636, 638 Pakete defekte 268 doppelte 270 Paket-Fragmente 335f., 353 Paket-Verstümmelung 45 Protocol 235, 278 Qualitätssicherung 284 Reaktionen von TCP 50 Remote Route Change 333, 335, 337ff. Remote Route Long Way 339 Report über 22.661 IP Hosts 557 Route Route Change 345 Router-Hop 215, 217 Routing-Fehler (1) 276 Routing-Fehler (2) 277

681

Stichwortverzeichnis

– – – – – – – – – –

Routing-Fehler (3) 277 Source Address 235, 279, 340 Source-Route ist vorhanden 252 Subnet Broadcast 246 Subnet Mask 253, 474 Subnet, IP-Adresse im falschen 282 TCP MSS 354 TCP/IP-Analyse 540 TCP/IP-Statistiken 538 Time To Live (TTL) 226, 235, 259, 275 – TM.SM.SpiderMagic.TABLES.~~IP~ ~.Hosts.CSV 404, 546 – TM.SM.SpiderMagic.TABLES.~~IP~ ~.Total.CSV 404, 546 – TM.SM.SpiderMagic.TABLES.~~IP~ ~.TXT 404, 546 – Top Talkers 538 – ToS 332 Normal/High Reliability 266 Normal/High Throughput 266 Normal/Low Delay 266 Routine Precedence 266 – ToS Normal/High Reliability 234 – ToS Normal/High Throughput 234 – ToS Normal/Low Delay 234 – ToS Precedence 234 – Total Length 234, 266, 354 – Total Length MAC Length 332 – TraceRoute 342 – TTL 210, 213, 215, 328, 337, 546, 603, 631, 639 – TTL = 0 337, 339, 346, 604 – TTL-Statistik 648 – Type of Service (ToS) 234, 265 – Version 234, 264, 332 – WINS 247 IPC 343, 347, 379, 577 – Client-Zugriff 379 – Inter Process Communication 49, 343, 347, 526 IPO, May/Don't Fragment (MF/DF) 234 IPX 285 J Jitter siehe VoIP JSPNRMPTGSBSSDIR siehe Name Services

682

K Kabel – Koax 167 – Twisted Pair 167 Kollision siehe Ethernet Kollisionen, Late Collisions 269 Kosten – Betriebsausfall 112 – Einsparungen 116 – externe 112 – Kostenrechnung 116 – Personal 112 Kritik siehe LAN-Analyzer L LAA 243 LAN-Adapter – Fehler 331, 346 – MAC Multiple Tx 331, 346 LAN-Analyse siehe Analyse LAN-Analysten, Ausbildung 105 LAN-Analyzer 33 – Anmerkungen 93 – Archivierungs-System 102 – ATM-Tester 42 – Capture Engine 171 – Datenbanken 86 – DHCP 45 – Fehlleistungen 41 – Filter 73 Datenbank 86 Fehler 73 – Gigabit 169 – Hardware-Analyzer 93, 99 – ICMP-Meldungen, unterdrückte 73, 328f. – Kinderspielzeug 517 – Kritik 33 – Messrechner 169 – Monitoring-Systeme 99 – Offline-Analyse 37 – Offline-Filter 78 – Online-Analyse 37 – Online-Filter 78 – Probleme 38 – Reports, fehlende 87 – Scheitern 37, 39, 41, 45f., 48, 50, 55, 73, 79, 81, 84, 86f., 327f., 394, 430, 549, 557, 664

>>> NEW TECH

Stichwortverzeichnis

Maximum Segment Size (MSS) siehe TCP Maximum Transmission Unit (MTU) 314 MCF siehe File Services Media Splitter siehe Messpunkte Messpunkte 122 – All Ports Mirroring 210 – Capture Engine 171 – Gigabit 169 – Load-Balancing 172 – Media Splitter 170 – Mirror Ports 169 – Mirror-Port-Fehler 215 – Multi Port Mirroring 210 – TAP 170 – TcpDump auf Server 172 – VoIP 611, 636 – Wahl der Messpunkte 517 Methodik, TCP/IP 241 Metric/Cost 275 Microsoft siehe Windows Migration (Netware, Windows) 394 Mirror Ports siehe Messpunkte MSS siehe Maximum Segment Size MTU 335f. – Siehe: Frames – Siehe: Router – Siehe: TCP – Siehe: WAN Multicast siehe Frames Mutationen – Siehe: File Services, Dateinamen, mutierte – Siehe: File Services, Pfad-Namen, mutierte

– Schelte 327 – Software-Analyzer 81, 93 – Software-Code 34 – Stand der Technik 25, 33 – Statistiken 37 – Statistiken, fehlende 549 – TCP Retransmissions 209 – TCP-Analyse 48 – TCP-Retransmissions 48 – unwirtschaftlich 664 – weltfremd 664 LANdecoder32 283 – Siehe: Hersteller LAN-Emulation siehe ATM LAN-Pakete – Siehe: Filter – Siehe: Frames LANreport 283 – Siehe: TraceMagic Late Collision 269 Layer siehe OSI LDAP siehe Protokolle LESBUS siehe ATM LLC 285 – LLC und DLC 26 – LLC und NetBEUI 26 – LLC-2(COLS) 27 – Siehe: Protokolle Load-Balancing 172, 334, 541, 601 M MAC – Broadcast 331 – I/G Bit 342 – MAC Address 43, 243 – MAC Padding 267 – MAC-Adresse, doppelte 244 – Multicast 331 – Retransmissions 271 MAC Address – Filter 73 – I/G Bit 616 – U/L Bit 616 – Verfälschung 43, 343, 615 MAC Layer siehe OSI Marktführer 100 Master-Slave siehe Sitzung Matrix siehe Verkehrsbeziehungen

>>> NEW TECH

N NAI siehe Hersteller Name Services 25, 29, 55, 127, 354, 359, 393, 423, 429, 503, 520, 571 – Antwortzeit, lange 55, 58, 368, 371, 382 – BOOTP 25 – Datei-Suche via DNS 360 – Dateisuche via DNS 55 – DHCP 25 – DNS 25, 29, 355, 360, 382, 393, 503, 514, 519, 584

683

Stichwortverzeichnis

– – – – – –

DNS-Suche via NDS 382 ICABROWSER 419 JSPNRMPTGSBSSDIR 59, 366 LMHOSTS 360, 367 MUP.SYS 383, 595 NetBIOS 25, 29, 357, 393, 503, 514, 518 – NetBIOS Name Service 356 – SMB-NCP-Konflikte 598 – UNC 369, 383 – Wartezeiten 368, 382 – WINS 25, 29, 356, 360, 377, 393, 503, 514, 517 – Siehe: Filter – Siehe: NetBIOS – Siehe: Zeichensätze Namensauflösung – DNS Name 248 – Namensabfragen, umgekehrte 249 NCP – Dateizugriffe, Nachweis aller 579, 591 – SMB-NCP-Konflikte 460, 598 – TM.SM.SpiderMagic.TABLES.~~ NCP~~.File.Handles.(Open.Close) .TXT 404, 468, 579 – Zugriffstabellen 468, 579, 591 NDS siehe Protokolle Net3Group 283 – NetSense 283 NetBEUI 26 – ASCII,ANSI,CIFS,Unicode 77 – Siehe: NetBIOS – Siehe: Protokolle – Siehe: Zeichensätze NetBIOS 29, 220 – ASCII,ANSI,CIFS,Unicode siehe Zeichensätze – Broadcast 285 – Browse 357 – CIFS 487 – DNS 355, 388, 390 – JSPNRMPTGSBSSDIR 59, 366 – LanManager for Unix 489 – LMHOSTS 360, 367, 478 – MSBROWSE 357 – Name Cache 478, 480 – Namen 357, 388, 390 – NBSTAT 356 – NetBEUI 59, 220, 360, 478, 487

684

– NetBIOS Datagram 357 – NetBIOS Name 248 – NetBIOS Name Service 356 – NetBIOS over IPX 59, 566 – NetBIOS over LLC 59, 566 – NetBIOS over TCP/IP 59, 566 – NetBIOS over UDP 518 – NetBT 59, 220, 356, 478, 566 – Resource Type 518 – Session Request 487 – Verbindungsaufbau 291 – WINS 356 – Siehe: Protokolle – Siehe: Zeichensätze NetBT siehe NetBIOS NetInstall 574 – NI5_FH.BAT 574, 587 – NiAgnt32.exe 572 – NiAgnt32.exe.Local 442, 455, 566, 598 – NiAgnt32.exe.Manifest 442, 455, 566, 598 – rc.files 568 NetSense 283 NetTool siehe Hersteller NetVCR siehe Hersteller NetWare – Client Requester 595 – Dateizugriffe, Nachweis aller 579, 591 – SMB-NCP-Konflikte 460, 598 – TM.SM.SpiderMagic.TABLES.~~ NCP~~.File.Handles.(Open.Close) .TXT 468 – Zugriffstabellen 579, 591 – Siehe: File Services – Siehe: Protokolle, NCP Network Associates, Inc. 283 Network General, siehe Hersteller Network Instruments 283 – Siehe: Hersteller Networker's Guide 329 Networker’s Guide 21, 25, 118, 347, 359, 479, 603 NetXRay siehe Hersteller Netzwerk – Revisionsfähigkeit 115 – Umgebung 106 Netzwerk-Drucken siehe Drucken NikSun siehe Hersteller

>>> NEW TECH

Stichwortverzeichnis

Novell – Siehe: File Services – Siehe: Protokolle, NCP NTOP siehe Hersteller NTUSER.DAT 68 O Observer 283 – Siehe: Hersteller Offset – TCP 288 – TCP Seq/Ack Number 298 – TCP Sequence Number, Rücksprung 300 – TCP, Fehler in der Offset-Folge 298 Oracle – IP Paket-Dreher 69 – Siehe: Protokolle OS/2 – Siehe: File Services – Siehe: Protokolle, SMB – Siehe: SMB OSI – Application Layer 30, 393, 403, 429, 473, 489, 503, 520, 609 – Data Flow Control 48 – Data Link Layer 25, 41, 167, 520 – MAC Layer 25, 41, 520 – Network Layer 25, 44, 403, 503, 520 – OSI Layer 1 25, 28, 39, 167 – OSI Layer 1-2 520 – OSI Layer 2 41, 167 – OSI Layer 2a 25 – OSI Layer 2b 25 – OSI Layer 3 44, 403, 503 – OSI Layer 3-4 25, 28, 327, 394, 520 – OSI Layer 4 48, 403, 429, 485, 503 – OSI Layer 5 487, 503 – OSI Layer 5-7 29, 55, 359, 503, 520 – OSI Layer 7 30, 61, 393, 403, 429, 473, 489, 503, 520, 609 – Physical Layer 25, 39, 167, 170, 520 – Session Layer 487 – Transport Layer 25, 48, 403, 429, 485, 503, 520

>>> NEW TECH

P Padding, MAC Padding 267 Pakete – doppelt, Local Loop 253 – leere, mit TCP PSH Flag 306 Pakete siehe Frames Paketgröße – IP Fragmentation fehlerhaft 252 – IP Fragmentation nicht erlaubt 252 Paket-Verdopplung siehe Frames, doppelte Physical Layer siehe OSI Ping-Pong 289 PMAP siehe Port Mapper Protocol Port Mapper Protocol 296 Produkte siehe Hersteller Programmierer 34 – C++ 35 Protokoll – ADS 78 – AppleTalk 78 – ARP 476 – BANalyzer 117 – BOOTP 25, 45, 473, 517 – BPDU 213, 602 – DHCP 25, 78, 356, 473, 514, 517 – DNS 25, 29, 77f., 355, 360, 382, 393, 519, 584 – Header 45 – HTTP 30, 349, 399, 403, 469, 621 – ICA 405 – ICMP 44, 328f., 353, 558 – IP 44, 538, 558 – Kerberos 651 – LDAP 542 – LLC 43, 360 – NCP 30, 61, 78, 382, 397, 403, 421, 468, 513, 579, 598 – NDS 78, 517 – NetBEUI 77, 220, 360, 478, 487 – NetBIOS 25, 29, 77, 220, 393, 487 – NetBIOS Datagram 357 – NetBT 478 – NFS 336 – NIS 517 – NTP 517 – Oracle 399, 542 – RPC 78 – RTCP 402, 610 – RTP 402, 610

685

Stichwortverzeichnis

– – – –

SAP (NetWare) 77 SLP 517 SLP (NetWare) 77 SMB 30, 61, 77, 357, 397, 403, 421, 473, 538, 566, 576, 579, 598 – SNA 43 – Spanning Tree 213, 602 – TCP 429, 538, 558 – TELNET 621 – TNS 399 – UDP 357 – VIP 566 – Voice over IP 336, 609 – VoIP 30, 72, 99, 336, 401, 609 – WINS 25, 29, 78, 356, 360, 377, 393, 517 Provider 28, 46, 50 Proxy Ports siehe TCP Q Qualitäts-Kontrolle 30f. – Kostenrechnung 116 – Planbarkeit 116 Qualitäts-Sicherung 31, 90, 113 – Abnahmeprotokolle 31, 115 – Erfolgskontrolle 116 – Ergebniskontrolle 31 – Kostenrechnung 31 – Leistungsnachweise 115 – Rüstscheine 116 Qualitätssicherung 284 – IP 284 – TCP 315 Quittungen, TCP ACKs, die keine sind 312 R RARP 242, 249, 279 rc.files siehe TraceMagic Real Time Protocol 266 Reconstructed Files siehe TraceMagic Registry 25f. – .REG 400 – EnableDeadGWDetect 351 – EnablePMTUBHDetect 351 – EnablePMTUDiscovery 351 Registry Guide 25, 118 Remote (Network) MONitoring siehe RMON

686

Reports siehe Analyse, Reports Request For Comment siehe RFC Resource Reservation Protocol 266 Retransmission – TCP Packets, retransmitted 300 – Siehe: Switch – Siehe: TCP Retransmissions 271 ReTx siehe Retransmissions RFC 35, 41, 44, 74, 120, 327f. – Analyzer 35 RIF siehe Token-Ring Ring Parameter Server 244 RMON 104, 108, 170, 230, 324 – Ferndiagnose 326 – RMON I 326 – RMON II 326 Router 46 – Black Hole Router 353, 639 – Buffer Overflow 346 – Default Gateway 250, 337 – Fehler 251, 331, 336, 346f., 395 – FIFO 69, 215, 420, 541, 601 – ICMP-Meldung Network Unreachable 605 TTL = 0 604 – IP Fragmentation fehlerhaft 252 – IP Fragmentation nicht erlaubt 252 – IP TTL zu gering 251 – MAC Multiple Tx 331, 346 – Mehrfachübertragung 50 – MTU 335f. – Pakete werden verworfen 251 – Router ist überlastet 252 – Router-Hop 215, 217, 338, 604 – Routing Tables 251 – Sende-Buffer 50 – Source-Route ist vorhanden 252 Routing 44 – Black Hole Router 353 – Dead Gateway Detection 351 – Empfänger nicht erreichbar 252 – Fehler 46f., 250, 346 – Hop Cost 604 – Hop Count 338 – Hop Credit 338 – ICMP-Meldungen, unterdrückte 47, 85, 328, 353 – IP Don't Fragment (DF) Bit 353 – IP Fragmentation fehlerhaft 252

>>> NEW TECH

Stichwortverzeichnis

– IP Fragmentation nicht erlaubt 252 – IP May Fragment (MF) Bit 353 – Local Loop 253 – MTU Black Hole Detection 351 – MTU Discovery 351 – Remote Route Change 339, 640 – Remote Route Long Way 339, 640 – Router-Hop 215, 217 – Routing-Fehler (1) 276 – Routing-Fehler (2) 277 – Routing-Fehler (3) 277 – Source-Route ist vorhanden 252 – TraceRoute 342 – TTL = 0 346 RPC siehe Protokolle RTCP, Port Auto-Detection 402 RTCP siehe Protokolle RTP – Port Auto-Detection 402 – Siehe: Protokolle – Siehe: Real Time Protocol RVSP siehe Resource Reservation Protocol S Samba – Siehe: File Services – Siehe: Protokolle, SMB – Siehe: SMB SAP siehe Protokolle SAP/R3 – SAPGUI-Probleme 70, 430 – SAPLOGIN.EXE 66, 430 – Siehe: Dateinamen – Siehe: File Services Schwan, der sterbende 52 Schwellwerte – IP 284 – Qualitätssicherung 284, 316 – TCP 316 Script 68 – .BAT 68, 129, 137, 400, 438, 521, 587, 599 – .CFG 400 – .CMD 68, 129, 137, 400, 438, 521, 599 – .INI 400 – .POL 129 – .REG 129, 400

>>> NEW TECH

– Batch File 400 – File Reconstruction 504 – Login-Script 68, 129, 137, 158 als DNS-Anfrage 384 – NTUSER.DAT 129 – rc.files 504 – Script Command Tracking 521, 587 – Script Follow-Up 504, 521 – Script-Abwicklung fehlerhafte 438 via DNS 382 – Stapelverarbeitungs-Datei 400 Sende-Buffer – Siehe: Router – Siehe: Switch Sequence Number siehe TCP Session, TCP Session Denial 543 Sessions, TCP 299 Shared Media 104 Shomiti 283 – Surveyor 283 – Siehe: Hersteller Signal Quality Error 271 Simple Network Management Protocol siehe SNMP Sitzung – Abbau 349, 397 – Abbruch 347, 349, 397, 543, 564 – Ablehnung 348 – Annahmestau 397 – Antwortzeiten 55 – Aufbau 348, 397, 543, 574, 577 – Authentication 49, 526, 545 – Authorization 49, 526, 545 – bi-direktional 49, 343f. – Keep Alive 344 – Master-Slave 49 – NetBIOS Session Request 487 – Peer-to-Peer 220 – SMB Session Setup 490 – SMB Verify Dialect 489 – TCP Retransmission 545 – TCP Session Denial 564 – TCP Signale Flags 430 – Tree Disconnect 587 – uni-direktional 49, 343f. – Verweigerung 543, 564 – Siehe: IPC

687

Stichwortverzeichnis

Sliding Window Flow Control 289 – Siehe: TCP SLP siehe Protokolle SMB – Browse 357 – CIFS 487 – Dateizugriffe, Nachweis aller 579, 591 – Denied Resources 423, 439, 538, 566 – Fehlzugriffe 538 – File Handle 492 – GETDC 477, 482, 574 – LanManager for Unix 489 – LSARPC 492 – Mailslot 357, 477, 575 – MSBROWSE 357 – NETLOGON 485, 492, 575 – Samba 489 – SAMR 492 – Session Setup 490 – Share-Zugriff 379 – SMB over IPX 566 – SMB over LLC (NetBEUI) 566 – SMB over TCP Port 445 (DirectHost) 576, 661 – SMB over TCP/IP (NetBT) 566 – SMB over Vines IP (Banyan) 566 – SMB-NCP-Konflikte 460, 598 – SMB-Statistiken 538 – TM.SM.SpiderMagic.TABLES.~~ SMB~~.Error.Files.CSV 405 – TM.SM.SpiderMagic.TABLES.~~ SMB~~.File.Handles.(Open.Close) .TXT 405, 579 – Tree Connect 379, 490 – Tree Disconnect 379, 587 – Tree ID 379 – Verbindungsaufbau 291 – Verify Dialect 489 – Zugriffsfehler 423 – Zugriffstabellen 579, 591 – Siehe: Protokolle – Siehe: Zeichensätze SNA – EBCDIC 75 – SNA-over-LLC 43 – Siehe: Protokolle – Siehe: Zeichensätze

688

Sniffer 283 – Format 333 – Siehe: Hersteller – Siehe: Trace-Dateien SNMP 108, 170, 230, 324 – Community String 325, 612 – private 326, 612 – public 325, 612 – SNMP und CMIP 325 – SNMP-over-IPX 325 – UDP 316 Software-Analyzer siehe LANAnalyzer Source-Routing 252 – Siehe: IP – Siehe: Routing – Siehe: Token-Ring Spanning Tree 602 – BPDU 602 – Forward Delay 214, 218 – Topology Change 213 SQL, SQL.INI 458 STACCer 169 Statistics, TCP Port Statistics 538 Statistiken – IP Host Events 538 – Online-Analyse 81 – Port Statistics 549 – Qualifizierung 62 – SMB-Statistiken 538 – TCP Port Statistics 549 – TCP/IP-Statistiken 538, 565 – TCP-Statistiken 429 – TM.PS.PortStatistics.TABLES.~~IPTCP-UDP~~.TXT 550 – Top Talkers 62, 538, 547 – Trace File Statistics 539 – UDP Port Statistics 549 – Siehe: Analyse Stichproben siehe Analyse Surveyor 283 – Siehe: Hersteller Switch – Buffer Overflow 346 – Cut-Through 184 – Fehler 43, 331, 333, 346, 395 – FIFO 69, 215, 345, 420, 541, 601 – Frame-Vervielfältigung 209 – Layer-3-Switch 40, 46, 49 – MAC Multiple Tx 331, 346, 617

>>> NEW TECH

Stichwortverzeichnis

– MAC Tables 214, 221 – Mehrfachübertragung 50 – Mirror-Port-Fehler 215 – NetBEUI-Applikation 221 – Pfad-Tabellen 218, 602 – Prioritäts-Steuerung 345 – Retransmission 184 – Sende-Buffer 50 – Spanning Tree 213, 602 – Statistiken 621 – Store-And-Forward 184 – Unicast, an Broadcast-Port 218 – VLAN 220, 602 Synapse:Networks 26, 36, 40, 100, 117, 120, 189, 328, 355, 603 – BANalyzer 117 – LANreport 118 – Networker’s Guide 25, 118, 329, 347, 359, 479 – RegCheck 26, 118 – Registry Guide 25, 118 – Report über 22.661 IP Hosts 557 – Verhandlungen mit US-Hersteller 100, 121 SysConnect siehe Gigabit T TAP siehe Messpunkte TCP 239, 429 – ACK Flag 240, 291 – Acknowledge Number 240, 288, 298, 486 – Acknowledgement (ACK) 223 – ACKs, ausstehende 309 – ACKs, die keine sind 312 – Analyse 286, 299, 315 – Antwortzeiten 328 – Applikations-Analyse 54, 403 – Auto-Detection 399, 469 – bi-direktional 288 – Black Hole Router 353 – Buffer Overflow 350 – Burst Mode 350 – Checksum 240, 313 – Code-Red-Virus 48 – Control Flags 240 – Data Flow Control 262, 287 – Data Offset (Length) 240, 304 – Data Offset (Length), Fehler 305 – Dead Gateway Detection 351 >>> NEW TECH

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

– – – – –

– –

– – –

Destination Port 239, 294 EnablePMTUDiscovery 314 Expertendiagnose 299, 315 Fast Response 328 FIN Flag 240, 291 FIN/RST fehlen 309 Flags 290, 306 Signale 347 Flags – Übersicht 291 Frozen Window 351 Garbage Byte 344 Handshake 294 Header 239, 287, 294 Hex-Dump 305 HTTP Proxy Ports 399, 469 HTTP-Analyse 469 Idle Time 48 IP Host Events 538, 556, 601 Keep Alive 48, 310, 328, 344, 612 MAC Broadcast 331, 342 MAC Multicast 331, 342, 615 Maximum Segment Size (MSS) 53, 224, 240, 294, 314 Missing Sequence 346 MSS 53, 350, 403, 486 MSS = 536 354, 632, 639 MSS Low 352, 354 MTU 335, 353 MTU Black Hole Detection 351 MTU Discovery 351 Netzwerk-Drucken 51 No ReTx Header Duplicate 346 IP Local Loop 345 IP Paket-Dreher 345 Offset-Folge, Fehler 298 Offset-Kennungen 288 Options 240 Packets, retransmitted 300 Port 51, 54, 294 HTTP 349 NCP 513 Port 1494 ICA 411 Port 445 Direct-Host 576, 661 Siehe: Protokolle Port Analysis 396f. Port Auto-Detection 399, 469 Port Statistics 403ff., 498, 538, 549

689

Stichwortverzeichnis

– – – – – – – – –

– – – – – – – – – – –

– – – – – – – – –

690

Port-Nachweis je Server 513 PSH Flag 240, 291 PSH Flag, Fehler (leere Pakete) 306 Qualitätssicherung 315 Reaktionen auf IP 50 Retransmission 40, 48f., 181, 191, 209, 328, 343f., 545, 560, 600, 632 Retransmissions, Typen 48, 343, 525 Retransmissions, unechte 49 ReTx FIN 349 Keep Alive 344 RST 349 SYN 348 ReTx Packet History 525 ReTx SeqNo PreTx SeqNo 343, 526 ReTx SeqNo = PreTx SeqNo 343, 526 Round Trip Delay 328 RST Flag 240, 291 Sendeaufforderung 289 Sendefreigabe 289 Sende-Offset 49, 343ff. Sequence 209, 345 Sequence Disordered 345 Sequence Number 49, 182, 191, 213, 239, 288, 298, 343ff., 486, 526, 603 Sequence Number, Rücksprung 300 Sequence, fehlende 328, 346 Services 513 Services doppelt via UDP und TCP 317 Session Denial 48, 543, 564 Session Reset 48 Session Setup 48 Sessions 299 Signal ACK = Acknowledge 53, 347 FIN = Final 53, 347, 349, 526 PSH = Push 51, 347 RST = Reset 53, 344, 347, 349, 526, 543, 564, 576 SYN = Synchronize 53, 343, 347f., 485, 526, 543, 576 URG = Urgent 347

– Signale Flags 347, 430 – Sitzungskommandos 403 – Sitzungsverhalten 404 – Sliding Window Flow Control 224, 289, 310 – Slow Response 48, 328 – Sockets, Auswahl 295 – Sockets, Well Known 295 – Source Port 239, 294 – Start-Offset 346 – SYN Flag 240, 288, 291 – SYN Flooding 48, 308, 349 – SYN, SYN-ACK 292 – SYN/RST Flags 308 – SYN-ACK, ACK 293 – Synchronize 48 – TCP Window (Size) 289 – TCP, Inc. 223 – TCP/IP-Analyse 540 – TCP/IP-Statistiken 538 – TCP-Analyse 48, 342, 403 – TCP-Pakete als Multicasts 44 – Three Way Handshake 290, 486 – TM.PS.PortStatistics.TABLES.~~IPTCP-UDP~~.TXT 404, 550, 555 – Top Talkers 538 – URG Flag 240, 291 – Urgent Pointer 240, 314 – Verbindungsaufbau 291 – Verbindungsaufbau MSS, Window Size 294 – Verbindungsaufbau SYN, SYNACK 292 – Verbindungsaufbau SYN-ACK, ACK 293 – Window Size 224, 240, 290, 294, 310, 350, 403, 612, 639 auf Null gefallen 311 ist eingefroren 311 sehr klein 311 wird nicht genutzt 312 – Window Size 536/576 52, 351, 632 – Window Size Frozen 351 – Window Size Low 350 – Window Size Zero 48, 51, 351 – Window, Frozen 311 – Windows Registry 351 – WWW Reset 53, 347, 349

>>> NEW TECH

Stichwortverzeichnis

TCP/IP 223, 327 – Adress- und Namensauflösung 242 – DNS Name 248 – DNS Server/IP Address 248 – Einleitung 223 – IP Fragmentation fehlerhaft 252 – IP Fragmentation nicht erlaubt 252 – IP TTL zu gering 251 – klassische Fehler 242 – NetBIOS Name 248 – Token-Ring 244 – Vorgehensweise 241 TCP-Analyse, Annahmestau 397 TcpDump siehe Hersteller Telnet, Telnet-Befehle via DNS 389 Terminal Server – Citrix Metaframe 154, 405 – ICA 405 – ICABROWSER 419 THG siehe Hersteller, Finisar Three Way Handshake 290 – TCP 290 TNS siehe Protokolle Token Ring 168, 244 – Abort Sequence 271 – ARB 342 – ATM 343 – RIF 342 – Ring Parameter Server 244 – Source-Routing 342 – SRB 342 Tools – Ping 342 – TraceRoute 342 Trace-Dateien 38, 120, 122 – Datei-Grenzen 120 – Sniffer-Format 333 – TcpDump-Format 503 – Trace-Formate 134 – Zeitfenster 38, 81 TraceMagic 26, 33, 328, 357 – - TM.SM.SpiderMagic.TABLES.~~ NCP~~.File.Handles.(Open.Close) .TXT 468 – .CSV 340, 357, 505, 533, 547, 550 – .DB 340, 505, 533 – .HTML 159, 340, 505, 533 – .TXT 340, 505, 533, 547, 550 – 3rd Party Memo 563 – ACCESS_FAILURE 369, 380, 574

>>> NEW TECH

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

– – – – – – – – –

Analyse, laufende 149 Analyse-Reports 36, 89 Anonymizer 360 Anwenderbericht 122 Application Layer 61 Applikations-Analyse 61, 129, 393, 395, 503, 521 ATM-Analyse 42 Auswertung noch vor Ort 518 Auto-Detection 399, 402 BANalyzer 117 Bayerischer Rundfunk 122 Benutzeranmeldung 134 Bundesverteidigungsministerium 121 Client-Server-Analyse 522 Client-Server-Dialoge 393 Conversation Pairs 496 Current Frame 580 Dateizugriffe, Nachweis aller 579, 591 Datenbanken 86, 533 Datenflussdiagramm 124 Device Detection 505, 512 DHCP 514 DNS 357 Einführung 117 Einstellungen 395, 505, 520, 522, 527 Ergebnis-Dateien siehe TraceMagic, Report-Dateien Ergebnisdaten, Verteilung 110, 547, 565, 663 Event-Codes 540 Event-Filter 159, 508, 531, 562, 570, 572, 598 Event-Log 120, 145, 147, 150, 181, 206, 217, 369, 376, 380, 508, 527, 529, 570 Event-Log, Legende 573, 580 Fehler, spontane 82 File Handle 129, 579 File Reconstruction 137, 504, 521, 587 File Services 61, 129 Filter 75 Filter-Datenbank 86 FilterMagic 124f., 504, 650 Anleitung 650 FindMagic 124, 126, 504

691

Stichwortverzeichnis

– Funktionen 395 – History-Datenbank 86 – HostMagic 124, 127, 340, 357, 361, 392, 476, 496, 503ff., 571 – HostPairs 496 – HTML 130 Projekt 663 – HTTP Port Auto-Detection 469 – HTTP Proxy Ports 399 – HTTP-Analyse 399, 469, 521 – Installation 117, 130 – IP Host Events 538, 556, 601 – IP Host Statistics 403 – IP-Adresstabelle 141, 340 – Knowledgebase 86, 416, 540, 562 – Konzept 122 – LANreport 34, 118 – Lizenz 132 – MS Excel 424, 497 – Name Services 55, 127, 139, 357, 359 – NCP-Analyse 397, 521 – NetBIOS 357 – Organigramm 124 – OSI Layer 1 39 – OSI Layer 2 41 – OSI Layer 3 44, 327 – OSI Layer 4 48, 327 – OSI Layer 5 55 – OSI Layer 7 55, 61 – Port Auto-Detection 399, 402 – Port Statistics 538, 549 – Projekt-Verzeichnis 536 – rc.files 137, 148, 156, 394, 397, 400f., 504, 521, 536f., 568, 587 – Reconstructed Files 140, 148, 394, 400, 568 – Related Frame 580 – Report über 22.661 IP Hosts 557 – Report-Dateien 147, 155, 340, 357, 505, 533f., 550, 619 – Report-Datenbanken 142, 146, 148, 155 – Report-Filter 159, 508, 562, 570, 572, 598 – Reports 123 – Report-Verzeichnis 147 – Rüstungskonzern 121 – Rx/Tx-Statistiken 514 – Script Command Tracking 521, 587 692

– – – – – – – –

– – – – – – – – – – – – – – – – – – – –

–

– – – –

Script Follow-Up 521, 587 SingleHosts 357, 496, 505 SMB Denied Resources 439, 538 SMB-Analyse 397, 521, 566, 574 SMB-NCP-Konflikte 460, 598 SMB-Statistiken 538 SNA-over-LLC 43 SpiderMagic 124, 128, 136, 340, 369, 377, 395, 397, 499, 503f., 520, 571 System Memo 562 Tabellengröße 507f., 524 TCP History-Tabelle 142 TCP Port Analysis 397 TCP Port Statistics 396, 403, 498, 538, 549 TCP ReTx Packet History 525 TCP/IP-Analyse 28, 120f., 137f., 327f., 340, 395, 499, 520, 522 TCP/IP-Statistiken 538 TCP-Analyse 342, 403, 525 Test-Beschränkung 117 TM.DD.DeviceDetection.TABLES.~ ~01~~.TXT 512 TM.HIT.FRAMES.* 508, 529 TM.HIT.FRAMES.*.LOG.TXT 156, 195, 508, 529f. TM.HIT.FRAMES.*.TXT 145, 150, 154 TM.HIT.FRAMES.01.* 457 TM.HIT.FRAMES.01.*.LOG.TXT 570 TM.HIT.FRAMES.01.~.001.LOG. TXT 404 TM.HM.HostMagic.TABLES.~~ SINGLE.HOSTS~~.CSV 514 TM.HM.HostMagic.TABLES.~~ SINGLE.HOSTS~~.TXT 514 TM.PS.PortStatistics.TABLES.~~ IP-TCP-UDP~~.TXT 404, 550, 555 TM.SM.SpiderMagic.TABLES.~~ HTTP~~.WWW.Statistics.TXT 404, 471 TM.SM.SpiderMagic.TABLES.~~ IP~~.Hosts.CSV 404, 546, 565 TM.SM.SpiderMagic.TABLES.~~ IP~~.Total.CSV 404, 546, 565 TM.SM.SpiderMagic.TABLES.~~ IP~~.TXT 190, 404, 546, 565 TM.SM.SpiderMagic.TABLES.~~ >>> NEW TECH

Stichwortverzeichnis

NCP~~.File.Handles.(Open.Close) .TXT 404, 579 – TM.SM.SpiderMagic.TABLES.~~ SMB~~.Error.Files.CSV 405 – TM.SM.SpiderMagic.TABLES.~~ SMB~~.File.Handles.(Open.Close) .TXT 405, 579 – Trace File Statistics 539 – Trace-Alias 138 – Trace-Analysis 149, 530 – Trace-Anon 360, 429, 503, 557 – Trace-Counter 143, 527 – Trace-Datei, neue 143, 457, 508, 527 – Trace-Events 150, 161 – Trace-Filter 139, 523 – Trace-Formate 134 – Trace-History 155, 533f., 659 – Trace-Menü 136 – Trace-Report 533 – Trace-Statistics 369, 396, 403, 532, 534, 538, 546 – UDP Port Statistics 538, 549 – User Memo 563 – Viewer 90, 111f., 114, 123, 134, 161 – VoIP 401 – Vorgangstitel 138, 506 – Vorschaufenster 530 – Windows BDC 513 – Windows PDC 513 – WINS 357, 517 – Wissensdatenbank 86, 416, 540, 562 – Zeichensätze 75 – Zeitfenster 112 – Zugriffstabellen 439, 579, 591 – Zyklus 114 – Siehe: Analyse – Siehe: Filter – Siehe: IP – Siehe: TCP – Siehe: UDP Transmission Control Protocol siehe TCP Transport siehe OSI Triticom 283 – siehe Hersteller Troubleshooting – Siehe: Analyse – Siehe: TraceMagic >>> NEW TECH

TTL, IP TTL zu gering 251 TTL siehe IP U UAA 243 UCP, Sockets, Auswahl 295 UDP 225, 241 – Analyse 316 – Auto-Detection 611 – Checksum 241 – Destination Port 241 – Doppelte Zugriffe 317 – Header 241 – Length 241 – Port 137 WINS 356, 514 – Port 138 NetBIOS 514, 518 NetBIOS Datagram 357 – Port 53 DNS 355, 514 – Port Auto-Detection 402 – Port Statistics 538, 549 – RTCP Ports 402, 611 – RTP Ports 402, 611 – Services doppelt via UDP und TCP 317 – SNMP 316 – Source Port 241 – TM.PS.PortStatistics.TABLES.~~IPTCP-UDP~~.TXT 550, 555 – Top Talkers 538 UNC – Siehe: File Services – Siehe: Name Services Unicast siehe Frames Unicode siehe Zeichensätze uni-direktional 343f. – Siehe: Sitzung Usability 286 User Datagram Protocol siehe UDP US-Hersteller 34, 100, 121 – Armutszeugnis 35 – Eigentümer 35 – Hilflosigkeit 36 – Programmierer 34f., 47, 119 – Verdienste 36 – Verhandlungen 36

693

Stichwortverzeichnis

V Verbindungsaufbau – TCP SYN/RST Flags 308 – TCP-NetBIOS-SMB 291 Verfügbarkeit – Anforderungen 113 – Vorgaben 104 Verifikation siehe Analyse Verkehrsbeziehungen, Matrix 50 Virus, Code Red 349, 526 VLAN 266 – Siehe: Switch Voice over IP – Port Auto-Detection 401 – Siehe: VoIP VoIP 336 – Analyse mit LANdecoder32 649 – Analyse mit Observer 613, 649 – Analyse mit Sniffer 649 – Analyse mit TraceMagic 636, 649 – Endpunkt 610, 646 – ISDN 609 – Jitter 613, 634 – Laufzeitschwankungen 613, 634 – Messpunkt 611, 636 – Paketverluste 631 – Port Auto-Detection 401, 611 – Router 609 – RTCP 610, 631 – RTP 610, 631 – Telefonanlagen 609 W WAN 397 – ATM-WAN 42 – Black Hole Router 353, 639 – CIR 634 – Dead Gateway Detection 351 – Durchsatz 350 – Fehler, versteckte 72, 328 – HTTP-Analyse 399 – ICMP-Meldungen, unterdrückte 46, 50, 73, 328f., 353, 639 – IP Host Events 538 – IP TTL 631, 639 – IP-Analyse 47, 327f. – IP-Fragmente 336 – Laufzeitschwankungen 634 – MTU 335f., 639

694

– – – – –

MTU Black Hole Detection 351 MTU Discovery 351 Overbooking 634 Paketverluste 632 Provider 28, 46, 48, 50, 121, 328, 621, 633 – Remote Route Change 333, 339, 640 – Remote Route Long Way 339, 640 – TCP/IP-Statistiken 538 – TCP-Analyse 47, 327, 397 – TM.PS.PortStatistics.TABLES.~~IPTCP-UDP~~.TXT 550, 555 – TTL Statistik 648 – Verbindungsfehler 46 – VoIP 72, 401 – Siehe: Load-Balancing Wavetech Wandel Goltermann siehe Hersteller Weitverkehrsnetze siehe WAN WildPackets siehe Hersteller Windows 25 – .REG 400 – BDC 513, 517 – Browse 357 – Client-Login 473 – Client-Server-Analyse 522 – Client-Start 473 – Dateinamen, mutierte 430 – Dateizugriffe, Nachweis aller 579, 591 – Dead Gateway Detection 351 – DESKTOP.INI 67, 462, 570 – DHCP 473 – DNS 360, 519 – DNS Server 355 – Fehlertoleranz 359 – GETDC 477, 482, 574 – Internet Name Service siehe WINS – IP Packet ID, Windows-Fehler 602 – JSPNRMPTGSBSSDIR 366 – Kerberos 651 – Knowledgebase 367 – LDAP 542 – LMHOSTS 367, 478 – LSARPC 492, 578 – Migration 519, 542 – MSBROWSE 357 – MTU Black Hole Detection 351

>>> NEW TECH

Stichwortverzeichnis

– – – – – – – – – – – – – – – – – – – – –

– – – – – – – – – – – – – –

MTU Discovery 351 MUP.SYS 383, 595 NBSTAT 356 NetBIOS 519 NetBIOS Resource Type 518 NetBT 356 NETLOGON 485, 492, 575 NFS 336 NTUSER.DAT 68, 570 PDC 481, 513, 517 Registry 25f. SAMR 492, 578 Security Account Manager 578 Share-Zugriff 379 SID 492 SMB Denied Resources 439, 538, 566 SMB-Analyse 397, 473, 566 SMB-NCP-Konflikte 460, 598 SMB-Statistiken 538 TCP Port 389 LDAP siehe Protokolle TCP Port 445 Direct-Host 576 siehe Protokolle TCP SYN Flooding 349 Terminal Server (WTS) 313 Tree Connect 379 Tree Disconnect 379, 587 Tree ID 379 UNC 383 Win2000 29, 59, 354, 394, 542 Win9x 29, 182, 334, 473, 542 Windows 9x 394f. Windows ME 334, 394, 542 Windows NT4 29, 182, 334, 349, 354, 394, 542 Windows XP 29, 334, 354, 394, 503, 542, 574, 629 WINS 356, 360, 477, 517 Zugriffstabellen 439, 579, 591

>>> NEW TECH

Windows-NT-Registry 231 – Default Gateway 250 – IP Subnet Mask 250 WINS 57, 60, 242, 247, 285, 356, 360, 377 – Antwortzeiten, lange 368 – Broadcast Node 479 – DHCP 356, 474 – Dummy-Einträge 367 – Hybrid Mode 479 – Hybrid Node 356 – IP-Adresse, PDC 481 – JSPNRMPTGSBSSDIR 59 – Knoten-Typ 356, 474, 479 – Lease 478, 480, 492 – Mixed Mode 479 – Namensabfragen, umgekehrte 249 – NBSTAT 356 – Node Type 356, 474, 479 – Peer to Peer Node 479 – Refresh 492 – Registration 477 – statische Einträge 367 – Wartezeiten 368 WWW 309 – TCP-Reset 53, 347, 349 – Siehe: Protokolle, HTTP Z Zeichensätze 75 – ANSI 75f. – ASCII 75f. – CIFS 75f., 487 – DNS 75, 77 – EBCDIC 75 – NetBEUI 77 – NetBIOS 77 – NetBT 77 – SMB 77 – Unicode 75f. – Siehe: Filter Zeitfenster siehe Trace-Dateien Zyklus 114

695

15 Fragen an den Autor

1.

Was ist Ihre nachhaltigste Erinnerung an die Zeit, in der Sie dieses Buch geschrieben haben? Dass die stürmische Entwicklung der Software »TraceMagic«, auf welcher das Buch beruht, ständig das Dilemma brachte: Muss das Buch nun schnellstmöglich fertig werden, um der Welt die guten Nachrichten mitzuteilen, oder sollte ich nicht noch schnell dieses und jenes zusätzlich programmieren, um auch diese schönen, neuen Möglichkeiten ebenfalls noch im Buch unterbringen zu können? Ich hätte noch fünf Jahre programmieren können, und das Buch wäre nie fertig geworden ... Ach, ja: »Der Weg ist das Ziel.« Das hilft, durchzuhalten.

2.

Welche technische Entwicklung der letzten Jahre hat es geschafft, Sie anhaltend zu faszinieren? TraceMagic. Wirklich – das ist so. Alles Andere ist inzwischen völlig uninteressant geworden. Binnen kürzester Zeit die Marktführer überholt zu haben, ist so spannend wie nichts sonst.

3.

Wie lange arbeiten Sie schon in der IT-Branche? Seit 1987, nunmehr also 15 Jahre.

4.

Was machen Sie als erstes, nachdem Sie ihren Rechner hochgefahren haben? Nachdenken.

5.

Welches war die längste Zeitspanne, die Sie je vor dem Computer verbracht haben? Non-stop? Etwa 50-60 Stunden. Aber das war vor zehn Jahren; heute wird die Resource »Gesundheit« pfleglicher behandelt.

6.

Für welches Gerät in Ihrem Haushalt wünschen Sie sich dringend eine Computerschnittstelle? Für keines – bitte nicht noch mehr davon.

7.

Welches ist Ihre Lieblingsanwendung unter Windows/Linux/KDE/ Solaris/etc.? TraceMagic (...sorry...)

>>> NEW TECH

697

15 Fragen an den Autor

8.

Für welchen Bedienungsfehler an einem Rechner könnten Sie sich heute noch ohrfeigen? Dafür, dass ich meinen Mini-Tower frei auf dem Boden stehen ließ in den Wochen, als unser Sohn das erste Krabbeln entdeckte. Im Alter von vier Monaten schaffte er den Weg von der Decke bis zum Schreibtisch selbständig, und als erste Amtshandlung seines Besuchs bei Papa drückte er zielgenau den grün beleuchteten Reset-Knopf. Okay, dafür würde ich mich nicht ohrfeigen. Aber lustig war's trotzdem!

9.

Wenn Sie Ihr Geld nicht in der IT-Branche verdienen müssten, wo und wie würden Sie dann arbeiten? Schwer zu sagen. Meine künstlerische Ader würde sich Bahn brechen, so viel ist sicher. Allerdings wären die Einkünfte ungewiss... also bliebe ich, was ich bin: Unternehmensberater. Auch ohne IT gibt es viel zu tun.

10.

Welches war das merkwürdigste Projekt, an dem Sie je beteiligt waren? Ich war Gutachter in einem Schadensfall, in dem sich ein Geschädigter, drei Dienstleister bzw. Lieferanten (alle weltweit tätig) und ein Hardware-Hersteller (ebenfalls weltweit tätig) auf mich als Sachverständigen geeinigt hatten. Der Hersteller hatte über Monate Behauptungen aufgestellt, von denen mir klar war, dass sie nicht stimmen konnten. In der entscheidenden Elefantenrunde mit rund zwölf Teilnehmern hatten alle anderen Parteien Angst, sich auf die Sichtweise ihres Gutachters einzulassen, weil sie es sich mit dem marktdominanten Hersteller nicht verderben wollten. Am Anfang stand einer (der Gutachter) gegen alle (da die anderen Parteien der Sprachregelung des Herstellers zu folgen geneigt waren, weil sie – wie gesagt – Sorge hatten, ihren Vorzugsstatus zu verlieren). Am Ende und nach vielen Stunden stand es wieder einer (der Hersteller) gegen alle: Der Hersteller bzw. dessen Vertreter musste am Ende, nach rund 6 anstrengenden Stunden, sogar zugeben, dass er die versammelte Runde die ganze Zeit über belogen hatte. Später, unter vier Augen, sagte der Hersteller-Vertreter: Dies sei der mieseste Tag seines Lebens gewesen; er sei mit dem klaren Auftrag geschickt worden, die Unwahrheit zu sagen, weil die Chef-Etage des weltweiten Hersteller-Konzerns fest davon ausgegangen war, dass es der Gutachter nicht schaffen würde, das Gegenteil zu beweisen und die drei Dienstleister (alle von Weltrang) zu überzeugen. Der Mann war fertig. Er tat mir leid. Der Hersteller übrigens hat danach jede weitere Zusammenarbeit mit dem Gutachter eingestellt. Verletzte Eitelkeit wäre da als Beschreibung wohl noch zu kurz gegriffen. Mir hat es die Bestätigung gegeben, dass die Wahrheit ein hohes Gut ist, und dass ich in meinem Job gut bin. Rückgrat kann sich auch lohnen.

698

>>> NEW TECH

15 Fragen an den Autor

11.

Schicken Sie uns bitte ein Foto von Ihrem Arbeitsplatz (unaufgeräumt).

12.

Nennen Sie uns Ihre Lieblings-Internet-Site. www.planetenflug.de

13.

Wie viele (EDV-)Bücher besitzen Sie? Welches war das erste, welches das letzte, das Sie gekauft haben? Besitz: vielleicht 100 Gelesen: die meisten Das erste: Turbo Pascal 6.0 Handbuch Das letzte: Jahre her. Die Bücher, die ich immer suchte, muss ich heute selber schreiben.

14.

Wo wird Networker's Guide in fünf Jahren sein? Vom Konzept her wie heute: Aktuelle, praxisbezogene Nachweise zu LAN-WAN-Fehlern der zeitgenössischen Technik, zur sicheren Methodik der Diagnostik, sowie möglichst viele Hinweise zu Möglichkeiten, die erkannten Fehler zu beheben.

15.

Wo werden Sie in fünf Jahren sein? Möglicherweise in den USA, um die US-Hersteller auf ihrem eigenen Heimatmarkt zu schlagen. Ansonsten weiter im beschaulichen Bonn, das mir gut tut.

>>> NEW TECH

699

Der Autor über sich

Geboren 1960 in Bremen, aufgewachsen in Bremen, Wien und Düsseldorf, waren früh die Grenzüberschreitung wie das Vermittelnde auch lebensnah und selbstverständlich. Dies gilt auch für so widersprüchlich erscheinende Ausbildungen wie die zum Funker, zum Kirchenmusiker und zum Geisteswissenschaftler (Uni Bonn: Geschichte, Philosophie, Germanistik) einschließlich mehrjähriger, ernsthafter Beschäftigung mit der »Kritik der reinen Vernunft« und dgl. mehr von Immanuel Kant. Auch für so weit gespannte Aktivitäten wie das Schreiben eines Reiseführers »Mit dem Inter-Rail-Ticket durch Europa« und das Herstellen und Verkaufen von Gedichtbänden (zum Finanzieren des Studiums über Selbstverlag) blieb noch Zeit. Das Ableisten des Zivildienstes in einer Tagesstätte für geistig und körperlich Schwerstbehinderte, das Leiten eines Kirchenchors während dieser Zeit sowie das Gründen des Landesverbandes Bremen der Jungen Liberalen (FDP) und einer mehrjährigen politischen Betätigung sind Zeichen meiner Vielseitigkeit. Das Leben ist bunt, und alles gehört irgendwie zusammen. »Alles beeinflusst sich«, sagten schon die alten Griechen. Der Zusammenhang zum Beruf? Jeder macht mit; keiner macht, was er soll; allen macht's Spaß; und am Ende steht der Daten-GAU. So ist es, wenn verschiedenste Betriebssysteme, Applikationen, Subsysteme und Baupläne heterogen zusammen gewürfelt werden; wenn Abteilungen nicht mit einander, sondern gegen einander arbeiten; wenn die Linke nicht weiß, was die Rechte tut, weil allerorten falsche Vorstellungen darüber bestehen, was im Hintergrund wirklich geschieht. Das Mysterium will enträtselt sein, und die Freude am Detektivischen lässt dann nicht los. Wie im Krimi heißt es, allen Spuren nachzugehen, keine außer Acht zu lassen, keine losen Enden übrig zu behalten, zum Schluß ein ganzes Netz logischer Schlussfolgerungen nachvollziehbar ausbreiten zu können. Und mittendrin: der Mensch. Als Maßstab aller Dinge?

>>> NEW TECH

701

Der Autor über sich

Die Gründung von Synapse:Networks war eine Folge der Zwanghaftigkeit, den Dingen auf den Grund gehen zu wollen. Und sie bot sich an, weil es immer wieder Kunden gab, die genau das nachfragten – meistens, wenn jahrelanges Wegsehen nicht mehr verlängerbar war. Erst eine One-Man-Show, wuchs die Firma über die Jahre bis zu einem arbeitsteiligen Dienstleister, dessen eindeutiger Schwerpunkt Handel, Training und Dienstleistung im Bereich der LANAnalyse war. Dann kam die Marktsättigung im Bereich herkömmlicher LAN-Analyzer in Sicht (was neue Produkte erforderte), und es kam Gigabit in Sicht (dessen Datenmengen ebenfalls neue Produkte erforderte), und es drängte Windows 2000 auf den Markt (dessen Fehler neue Nachweismethoden nahe legten); und Synapse:Networks entschloss sich, von der Händler- auf die Hersteller-Seite zu wechseln. Heute ist Synapse:Networks weltweit führend mit dem LAN-Analyse Experten-System TraceMagic und den darauf basierenden Dienstleistungen. Die ehemaligen Mitarbeiter sind heute selbständig als Wiederverkäufer, weil sie das Marktpotenzial als Grundlage ihrer wirtschaftlichen Existenz erkannt hatten – und weil ein Hersteller eben seinen Reseller braucht. Der Markt verlangt Arbeitsteilung. Grenzen überschreiten und über sie hinweg vermitteln: Das könnte als Motto privat wie beruflich gelten. Schon dem ersten Networker's Guide (2000) war anzumerken, dass eine ganzheitliche Sicht der Dinge durchgängig vermittelt wurde. Dieser Ansatz ist im neuen Networker's Guide (2003) noch klarer, noch umfassender verwirklicht. Den Leser mitzunehmen auf eine Reise, die für ihn spannend ist, aber auch entspannend, hilfreich und lehrreich, unterhaltsam und wirtschaftlich nutzbar: Dies war das selbst gesteckte Ziel, und wenn es wieder Mails zufriedener Leser geben sollte, die dies in eben diesem Sinne verstanden haben, so war die Arbeit nicht vergebens. Ein Leser des ersten Networker's Guide schrieb, das Buch müsse unter Zensur gestellt werden, weil er nun schon die zweite Nacht in Folge gelesen, aber nicht geschlafen hätte: es wäre zu unterhaltsam, zu spannend, zu praxisnah gewesen, um es weg zu legen. Ich wünsche mir, ich wünsche Ihnen, dass es uns alle in diesem Sinne packt und nicht los lässt. Wenn es aufhört, Spaß zu machen, sollten wir es aufgeben! Und damit genau das nicht geschieht, liegt dieses Buch nun vor.

702

>>> NEW TECH

Copyright Daten, Texte, Design und Grafiken dieses eBooks, sowie die eventuell angebotenen eBook-Zusatzdaten sind urheberrechtlich geschützt. Dieses eBook stellen wir lediglich als Einzelplatz-Lizenz zur Verfügung! Jede andere Verwendung dieses eBooks und zugehöriger Materialien und Informationen, einschliesslich der Reproduktion, der Weitergabe, des Weitervertriebs, der Plazierung auf anderen Websites, der Veränderung und der Veröffentlichung bedarf der schriftlichen Genehmigung des Verlags. Bei Fragen zu diesem Thema wenden Sie sich bitte an: mailto:[email protected]

Zusatzdaten Möglicherweise liegt dem gedruckten Buch eine CD-ROM mit Zusatzdaten bei. Die Zurverfügungstellung dieser Daten auf der Website ist eine freiwillige Leistung des Verlags. Der Rechtsweg ist ausgeschlossen.

Hinweis Dieses und andere eBooks können Sie rund um die Uhr und legal auf unserer Website

(http://www.informit.de) herunterladen