Networkers Guide - new technology . LAN Analysis & Windows Troubleshooting

networker´s guide LAN analysis & windows troubleshooting

networker´s guide LAN analysis & windows windows troubleshooting troubleshooting

frank r. walther

new technology

Markt&Technik Verlag

Die Deutsche Bibliothek – CIP-Einheitsaufnahme Ein Titeldatensatz für diese Publikation ist bei der Deutschen Bibliothek erhältlich.

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 Software-Bezeichnungen, 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. Die Einschrumpffolie – zum Schmutz vor Verschmutzung – ist aus umweltverträglichem und recyclingfähigem PE-Material.

10 9 8 7 6 5 4 3 2 03 02 01 00

ISBN 3-8272-5739-5 © 2000 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 Lektorat: Angelika Ritthaler, [email protected] Herstellung: Ulrike Hempel, [email protected] Satz: reemers publishing services gmbh i. Gr., Krefeld CD-ROM-Programmierung: piXeleye interactive new media design, www.piXeleye.de - E-mail: [email protected] CD-ROM-Realisation: Dirk Behlau Co-Autor: Oliver Thewes Einbandgestaltung: Luna Design GmbH, Feldkirchen Druck und Verarbeitung: Bercker, Kevelaer Printed in Germany

Inhaltsverzeichnis Kapitel 1

Kapitel 2

Vorwort

23

Das Werkzeug

25

1.1 1.2 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.2.6 1.2.7 1.2.8 1.2.9 1.2.10 1.2.11 1.3 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 1.3.6 1.3.7 1.3.8 1.4

26 27 27 29 30 31 31 33 43 45 48 48 52 52 53 55 57 57 58 58 58 59 60

Kriterien für LAN-Analysatoren Grundfunktionen Bedienbarkeit und Training Hardware-Nähe Promiscuous Mode Monitoring vs. Analyse Capturing Filtering Endlosaufzeichnungen Expertendiagnose Auto-Learning Protocol Decoding Zwischenfazit Geräteklassen Local Analyzer <> Remote Analyzer Hardware-Analyzer <> Software-Analyzer Hand-held Analyzer <> PC-Analyzer Echtzeit-Analyzer <> Nicht-Echtzeit-Analyzer Online-Analyzer <> Offline-Analyzer Dual-Port Analyzer <> Single-Port Analyzer External Analyzer <> Internal Analyzer Active Analyzer <> Passive Analyzer Fazit

Hersteller und Produkte

61

2.1 2.1.1 2.1.2 2.1.3

62 62 62 62

Analyse: Software-Produkte AG Group: EtherPeek/TokenPeek Chevin: CNA Pro/LAN Fox Cinco: NetXRay

6

Inhaltsverzeichnis

2.1.4 2.1.5 2.1.6 2.1.7 2.1.8 2.1.9 2.1.10 2.1.11 2.1.12 2.1.13 2.1.14 2.1.15 2.1.16 2.1.17 2.1.18 2.2 2.2.1 2.2.2 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 2.3.7 2.3.8 2.3.9 2.3.10 2.3.11 2.3.12 2.3.13 2.3.14 2.3.15 2.3.16 2.3.17 2.3.18

GN Nettest: InterWatch/Win Pharaoh Hewlett-Packard: Internet Advisor Ipswitch: What’s Up Gold LMC: CINeMa NAI/Network Associates, Inc.: Sniffer NDG Software: EtherBoy/PacketBoy Net3Group: NetSense/ProConvert Network Instruments: (Distributed) Observer Novell: LANalyzer for Windows/ManageWise Precision Guesswork: LANwatch32 RADcom: RC-88 – RC-100 RzK: NetQ&A – NetControl Shomiti: Surveyor/Century Tap Triticom: LANdecoder32 Wavetek Wandel Goltermann: Domino Analyse: Hardware-Produkte Fluke: OneTouch – LAN Meter Microtest: Omni/Penta/Micro Scanner Shareware/Freeware 4Net Any Speed Big Brother Free Wizard IDyle GimmIP Internet Anywhere Toolkit Internet Maniac IP Network Browser IP Sentry IP Subnet Calculator NeoTrace NetCat NetoScope Netscan Tools Ping Plotter PortFlash Recon-1 lite Remote Logout

63 63 63 63 64 64 64 64 65 65 65 65 66 66 66 67 67 67 67 67 67 68 68 68 68 68 68 69 69 69 69 69 69 70 70 70 70

Inhaltsverzeichnis

2.3.19 2.3.20 2.3.21 2.3.22 2.3.23 Kapitel 3

7

Remotely Possible Servers Alive? Sniff It Subnet Wiz Visual Route

Grundlagen der Methodik 3.1 3.2 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 3.3.7 3.3.8 3.3.9 3.3.10 3.4 3.4.1 3.4.2 3.4.3 3.5 3.5.1 3.5.2 3.5.3 3.6 3.7 3.8 3.9 3.10 3.11 3.11.1 3.11.2 3.11.3

Eingrenzung von Maschine, Schicht, Ort Die klassischen Netzwerkfehler Erste Schritte Interner oder externer Techniker? Dokumentation – ja oder nein? Der erste, schnelle Überblick Eingrenzung des Ortes Eingrenzung der Netzwerkschicht Verkehrstabellen Fragen und Antworten/Ausscheidungssystem Drei-Punkt-Messungen Drei-Generationen-Messung Reproduktion des Fehlers Die Windows-Registry HKLM\System\CurrentControlSet\ exportieren Registry-Tools zum Durchforsten der *.REG Systemsteuerung\Netzwerk: Vade retro! Deutung der Ereignisse und Messdaten Misstraue dem Kunden bzw. Anwender! Misstraue den Fehlermeldungen der Rechner! Wertvolle vs. wertlose Statistiken Statistik in Intervallen: Snapshots Trace-Bibliotheken – ein wertvolles Gut! Online-Publishing im Ernstfall Psychologie und Nervenstärke! Vorbeugen ist besser als Bohren Permanente Qualitätssicherung Kosten Einsparungen Garantierte Verfügbarkeit

70 70 71 71 71 73 74 75 76 77 77 78 79 80 81 82 85 85 87 87 87 89 90 91 91 91 92 98 100 101 102 103 104 104 105 105

8

Kapitel 4

Kapitel 5

Kapitel 6

Inhaltsverzeichnis

Statistik vs. Analyse

107

4.1 4.2 4.3 4.4 4.4.1 4.4.2 4.4.3

108 115 121 122 122 123 124

Frage und Antwort: Welche Messung? Zweiter Anlauf Dritter Anlauf und letzte Klärung Das Ergebnis Statistik vs. Analyse »Das Netzwerk ist zu langsam« Fazit: Wechselspiel von Statistik und Analyse

Switches und Mirror Ports

125

5.1 5.2 5.3 5.3.1 5.3.2 5.3.3 5.4 5.4.1 5.4.2 5.5 5.5.1 5.5.2 5.6 5.7

126 126 127 127 128 129 129 129 130 131 131 132 132 133

Messungen in Shared Media LANs Messungen in Switched LANs Half-Duplex Ports Mirror Port Repeater/RLV Media Taps/Media Splitter Full-Duplex Ports Rücksetzung auf Half-Duplex Media Taps/Media Splitter Messung auf der Seite der Endgeräte Und wieder: Shared Media LAN Eingeschränkter Nutzen des Full-Duplex-Betriebes Eingriff ins System: Gefährlich! Messungen am Switch: Media Tap!

Notfallmessungen

135

6.1 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.1.6 6.1.7 6.1.8 6.2

136 136 136 137 138 138 139 139 139 140

Abgestimmtes, gemeinsames Vorgehen! Angaben zum Störfall/Analysefragebogen Ansprechpartner/Vorbereitungen Ihrerseits Wie es losgeht = Warum wir wenig reden Runder Tisch: Alle müssen da sein! Weitere Vorgehensweisen Der Messbericht Reaktionszeit verkürzen = Teamarbeit! Schnell ans Ziel gelangen! Online-Fragebogen im Internet

Inhaltsverzeichnis

Kapitel 7

Kapitel 8

9

Kritik der LAN-Architekturen

147

7.1 7.1.1 7.2 7.3 7.4 7.4.1 7.4.2 7.4.3 7.4.4 7.5

148 148 151 157 158 159 159 160 160 161

Kritik des Shared Media LAN LAN – Last Area Network Das Funktionsprinzip herkömmlicher LANs SAN statt LAN bei der Datenhaltung IPv6, RSVP, L3-Switching, Network Policy QoS, Echtzeit etc. – wer erhält welche Dienstgüte? Policy Based Networks Netzwerkmanagement VLANs, Netzwerk- und Projektmanagement Fazit

Das OSI-Modell

163

8.1 8.2 8.3 8.4 8.4.1 8.4.2 8.4.3 8.5 8.5.1 8.5.2 8.6 8.6.1 8.6.2 8.6.3 8.6.4 8.7 8.7.1 8.7.2 8.7.3 8.7.4 8.8 8.8.1 8.8.2 8.9

164 165 166 166 166 166 166 167 167 167 168 168 168 169 169 169 170 170 170 170 171 171 171 171

Normierungen Protokolle = festgelegte Verfahrensregeln Die sieben Schichten Layer 1: Physical Serielle Bitübertragung A/D-Wandler Prüfsummen Layer 2: Data Link Layer 2a: MAC = Media Accress Control Layer 2b: LLC = Logical Link Control Layer 3: Network Modem Sharing – Gateways – Router Netzwerkadressen Router Exchange Protocols Layer 3 – verbindungslos/ungesichert Layer 4: Transport Layer 4 – verbindungsorientiert/abgesichert Datenfluss-Steuerung Handshake/Verbindungsaufbau und -abbau Quick And Dirty Layer 5: Session Login/Authentisierung Zugriffsschlüssel Layer 6: Presentation

10

Inhaltsverzeichnis

8.9.1 8.9.2 8.10 8.11 Kapitel 9

Lo/Hi – LSB/MSB – Little/Big Endian Zeichensatztabellen Layer 7: Application Header, Trailer, Daten: SDU+PCI=PDU

171 172 172 173

Physical Layer

175

9.1 9.2 9.2.1 9.2.2 9.2.3 9.2.4 9.2.5 9.2.6 9.2.7 9.2.8 9.2.9 9.2.10 9.2.11 9.2.12 9.2.13 9.2.14 9.2.15 9.2.16 9.3 9.3.1 9.3.2 9.3.3 9.3.4 9.3.5 9.3.6 9.4 9.4.1 9.4.2 9.4.3 9.4.4 9.4.5

176 176 176 177 177 177 177 178 178 178 179 179 179 179 179 180 181 182 182 183 183 185 185 186 187 188 189 190 192 193 194

Vorbemerkung Physical Coding Bit-Codierungen im Shared Media LAN Signal-Kodierung/binär Signal-Kodierung/ternär Signal-Kodierung & Kabel Takt-Rückgewinnung/Synchronisation Die gängigsten Binär-Kodierungen RZ – Return to Zero NRZ – No Return to Zero NRZ-L – No Return to Zero/Level NRZ-M – No Return to Zero/Mark NRZ-S – No Return to Zero/Space Manchester Code: Ethernet – 10 Mbps Differential Manchester: Token Ring – 4/16 Mbps 4B/5B: FDDI – 100 Mbps 8B/6T: Fast Ethernet – 100 Mbps 8B/10B: Gigabit Ethernet – 1000 Mbps Die häufigsten Fehlerquellen in der Physik Netzeingangsstrom: Network BIAS Phasenverschiebungen/Jitter Abfallzeit: Fall Time Bit-Rate: bit rate Einwirkende Störstrahlungen Relaisschaltungen: Token-Ring Das Auffinden von Fehlern in der Physik Kabeltester Twisted-Pair-Verkabelungen Koax-Kabel Token-Ring mit IBM Typ-1 Kabel Netzwerk-Management mit SNMP+RMON

Inhaltsverzeichnis

9.4.6 9.4.7 9.4.8 9.4.9 9.4.10 9.5 Kapitel 10

Kapitel 11

11

Eingrenzungen mittels Verkehrstabellen Der LAN-Analyzer ist unverzichtbar Beachtung von OSI-Schicht 3/Network Beachtung von OSI-Schicht 4/Transport Fazit: Wozu dient ein Kabeltester? 8B/6T Code-Tabelle

195 199 200 201 201 202

MAC Layer

205

10.1 10.1.1 10.1.2 10.1.3 10.1.4 10.2 10.2.1 10.2.2 10.2.3 10.2.4 10.2.5 10.2.6 10.2.7 10.2.8 10.3 10.4

206 206 206 206 208 208 209 210 210 210 212 213 215 216 217 218

Media Access Control Kernfunktionen von MAC Die Zugriffsberechtigung Das MAC-Protokoll Die Adressierung: MAC-Adressen Der Aufbau der MAC-Adressen Manufacturer ID und Node ID OUI = Organizationally Unique Identifier LAA und UAA I/G-Bit und U/G-Bit MSB/LSB – kanonisch/non-kanonisch Unterschiedliche Darstellung logischer Adressen Sicherheit vor MAC-Spoofing und Hackern MAC-Spoofing und IP-Spoofing Die Sicherung: Prüfsummen Varianten im Zugriffsverfahren

Fehler auf dem MAC-Layer

219

11.1 11.1.1 11.1.2 11.1.3 11.1.4 11.1.5 11.2 11.2.1 11.2.2 11.2.3 11.3

220 220 220 221 221 221 222 222 225 226 226

Doppelte MAC-Adresse(n) (LAA) Das Szenario Lokaler Konfigurationsfehler Fernkonfiguration mittels RPS Nachweis von doppelten MAC-Adressen Behebung des Fehlers Broadcast Stroms Mögliche Ursachen von Broadcast Storms Nachweis von Broadcast Storms Abhilfe bei Broadcast Storms Spanning Tree Bridges

12

Inhaltsverzeichnis

11.3.1 11.3.2 11.3.3 11.3.4 11.4 Kapitel 12

Die Spanning Tree BPDU Bridge ID/Bridge Priority Nachweis von Spanning-Tree-Fehlern Spanning Tree Timer Die Bedeutung der Analyse auf Schicht 2–7

227 231 232 234 235

Ethernet

237

12.1 12.1.1 12.1.2 12.1.3 12.2 12.2.1 12.2.2 12.3 12.4 12.4.1 12.4.2 12.4.3 12.4.4 12.4.5 12.4.6 12.4.7 12.4.8 12.4.9 12.5 12.6 12.6.1 12.6.2 12.7 12.7.1 12.7.2 12.7.3 12.7.4 12.8

238 238 239 240 241 241 242 242 244 246 246 248 248 250 251 251 253 254 254 257 257 265 266 266 267 268 268 268

Einführung Ethernet und Physical Layer Der Ethernet-Frame Ethernet – keine leichte Sache Vorgehensweise Eingrenzung von Ort und Ursache Ort/Topologie/Protokoll Physical Layer: die Ethernet-Hardware Ethernet Collisions – CSMA/CD »Carrier Lost« »Late Collisions« »Phantom Collisions« »Local Collisions« vs. »Remote Collisions« »Runts« »CRC Error« »Alignment Error« »Frame Short« »Frame Long«/»Jabber« Eingrenzung physikalischer Fehler Ethernet Frame-Typen Die verschiedenen Frame-Typen Fehler beim Frame-Typ und ihre Erkennung Bridges/Switches, Spanning Tree & BPDU Das Konzept der Transparent Bridges Fehler: zu lange Umschaltzeiten Fehler: falsche (= zu langsame) Ersatzwege Filter auf BPDU Ethernet Multicast Addresses

Inhaltsverzeichnis

Kapitel 13

13

Token-Ring

271

13.1 13.2 13.3 13.3.1 13.3.2 13.4 13.4.1 13.4.2 13.4.3 13.4.4 13.4.5 13.4.6 13.4.7 13.4.8 13.4.9 13.4.10 13.4.11 13.4.12 13.4.13 13.4.14 13.4.15 13.4.16 13.4.17 13.4.18 13.4.19 13.4.20

272 274 275 275 277 278 278 279 280 281 281 282 282 285 285 286 289 290 290 292 294 296 297 297 298

13.5 13.5.1 13.5.2 13.6 13.6.1 13.6.2 13.7 13.7.1 13.7.2

Einführung Das Werkzeug Der Token-Ring Header Aufbau des Token-Ring Headers SDU+PCI=PDU Das MAC-Protokoll: Funktionen und Filter SD – Starting Delimiter AC – Access Control FC – Frame Control MAC Destination/Source Address FCS – Frame Check Sequence ED – Ending Delimiter FS – Frame Status Information – LLC Data/MAC Data MAC Frames mit MVID und SVID Filter auf MVIDs Neuer Adapter im Ring DAT/Duplicate Address Test NAUN Process/Ring Poll Process Soft Errors/Fehlermeldungen Isolating/Non-Isolating Soft Errors Ring Error Monitor (REM) Ring Purge Beacon Process Claim Token/Monitor Contention Process Ring Parameter Server (RPS)/ Configuration Report Server (CRS) Vorgehensweise in der Analyse Eingrenzung von Ort und Ursache Ort des Fehlers in der Ring-Topologie Filter auf das MAC-Protokoll Filter sind schön, aber gefährlich! Filter auf Token-Ring Source-Routing Frames Die logischen Adressen von Token-Ring Das Prinzip der logischen Adressen Fest vergebene logische Adressen

299 300 300 301 302 302 304 306 306 307

14

Inhaltsverzeichnis

13.7.3 13.8 13.8.1 13.8.2 13.8.3 13.8.4 13.8.5 13.9 13.9.1 13.9.2 13.10 13.10.1 13.10.2 13.11 13.12 13.13 13.14 Kapitel 14

Kapitel 15

Kapitel 16

Funktionsadressen am Beispiel des RPS Token Ring Source-Routing »Ring Number« Das Routing Information Field (RIF) Wegewahl: ARB, SRB, Explorer Frame Mehrere Wege Konkurrierende Routing-Angaben Token Ring Access Priority Zugriffsprioritäten Schieflage: Router und Server vs. Brücken Ferndiagnose via RMON und CMOL RMON CMOL und OS/2 LAN Network Manager Token-Ring, LLC-SNAP und Ethernet Transparent vs. Source-Route Bridging TokenSwitching Ausblick: Der Ring lebt (noch)

308 309 309 310 313 314 314 316 316 318 319 319 319 320 321 321 322

LLC: Logical Link Control

325

14.1 14.1.1 14.1.2 14.1.3 14.1.4 14.2 14.3 14.3.1 14.3.2 14.4

326 326 326 326 327 328 328 329 330 335

LCC-Treibervarianten LLC und NetBIOS LLC und NetBEUI LLC und DLC LLC-1 (CLLS) und LLC-2 (COLS) LLC auf OSI Layer 2b: Abstraction Layer Der LLC-Header (PCI) Service Access Points (SAP) Control LLC-Analyse

SNAP: SubNetwork Access Protocol

337

15.1 15.2

Wozu SNAP? SNAP-Analyse

338 339

TCP/IP – Die DoD-Protokolle

341

16.1 Einführung: Was ist TCP/IP? 16.1.1 Sie erben »TCP, Inc.« und führen es zum Erfolg

342 342

Inhaltsverzeichnis

16.1.2 16.1.3 16.1.4 16.1.5 16.1.6 16.1.7 16.2 16.2.1 16.2.2 16.2.3 16.2.4 16.2.5 16.2.6 16.2.7 16.3 16.4 16.4.1 16.4.2 16.4.3 16.4.4 16.4.5 16.4.6 16.4.7 16.4.8 16.4.9 16.5 16.5.1 16.5.2 16.5.3 16.5.4 16.6 16.6.1 16.6.2 16.6.3 16.6.4 16.6.5 16.6.6 16.6.7

15

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 Details und weitere Protokolle 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 Address 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 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«

344 344 347 348 348 349 349 350 350 352 354 358 360 360 361 361 361 363 363 366 368 368 368 369 369 370 371 372 373 375 375 376 378 380 380 381 382 382

16

Inhaltsverzeichnis

16.6.8 16.7 16.7.1 16.7.2 16.7.3 16.7.4 16.7.5 16.7.6 16.7.7 16.7.8 16.7.9 16.7.10 16.7.11 16.7.12 16.8 16.8.1 16.8.2 16.8.3 16.8.4 16.8.5 16.8.6 16.8.7 16.8.8 16.8.9 16.8.10 16.9 16.10 16.10.1 16.10.2 16.11 16.11.1 16.11.2 16.11.3 16.11.4 16.11.5 16.11.6 16.11.7

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 SNMP/RMON SNMP: Befehls- und Abfragesprache SNMP-over-IPX SNMP und CMIP SNMP Community String »public/private« RMON: Ferndiagnose/Verkehrsanalyse HS-RMON Messtechnik im Bereich von TCP/IP

384 384 386 387 388 392 395 397 398 401 401 402 406 408 410 411 418 422 429 431 435 438 439 439 440 441 443 443 445 450 450 450 450 451 451 452 452

Inhaltsverzeichnis

Kapitel 17

Kapitel 18

17

TCP/IP – Unix /etc

453

17.1 17.1.1 17.1.2 17.2 17.3 17.3.1 17.4 17.4.1 17.5 17.6 17.7 17.7.1 17.7.2 17.8 17.9 17.9.1 17.10 17.10.1 17.10.2 17.10.3 17.11

455 455 456 456 456 457 457 458 458 459 459 460 460 460 461 462 462 464 464 464 464

/etc/passwd Achtung! NFS Achtung! UID=0 /etc/shadow /etc/group Achtung! NFS /etc/hosts Achtung: Local Host /etc/hosts.equiv /etc/networks /etc/gateways Achtung! route add Achtung! Redundanz vs Sicherheit /etc/protocols /etc/services Achtung! Nicht anfassen! /etc/exports Achtung! -anon=0 /etc/exportfs /etc/xtab /etc/ftpusers

TCP/IP Diagnose-Tools

465

18.1 18.1.1 18.1.2 18.1.3 18.1.4 18.1.5 18.1.6 18.1.7 18.1.8 18.1.9 18.2 18.2.1 18.2.2

466 466 467 467 468 468 469 470 471 471 472 472 473

Unix-Kommandos arp finger ipconfig lpq/lpstat netstat ping route [add {..} {..} ] snmp start|stop traceroute (WinNT: tracert) TCP/IP Diagnose-Tools für Windows Großes Netzwerkmanagement Kleine Netzwerk-Tools

18

Inhaltsverzeichnis

18.2.3 18.2.4 18.3 18.3.1 18.3.2 18.3.3 18.3.4 18.3.5 18.3.6 18.3.7 18.3.8 18.3.9 18.3.10 18.3.11 18.3.12 18.4 Kapitel 19

AnySpeed (PY Software, USA) What’s Up Gold (Ipswitch, USA) (Freundlicher) Angriff auf eine Website Einleitung: Nachahmung wird nicht empfohlen! Besuch bei der Fachhochschule Emden Schritt A: TraceRoute Schritt B: Finger Schritt C: Port Scan Schritt D: SNMP Get sysInfo/sysDescr Schritt E: SNMP Get ifPhysAddress Schritt F: SNMP Get ifInOctets Schritt G: DNS LookUp/weitere Betreiber des RZ Schritt H: DNS LookUp/Mail System Schritt I: Der Angriff auf das Mail-System Fazit Hacker-Tools

474 477 490 490 490 490 491 493 496 499 501 502 502 503 504 504

Troubleshooting mit TCP/IP

505

19.1 19.2 19.3 19.4 19.5 19.6

506 508 514 518 519 520

IP-Host antwortet nicht: Ping IP TTL (Time To Live): TraceRoute Routing-Fehler: ICMP & Expertendiagnose Netzwerk langsam: Durchsatzmessung IP-Pakete gehen verloren: Paketanalyse Filter setzen auf IP und ARP

Kapitel 20

NetWare IPX, SPX, NCP

523

Kapitel 21

Windows Networking

525

21.1 21.1.1 21.1.2 21.1.3 21.1.4 21.1.5 21.1.6 21.1.7 21.1.8

526 526 529 531 533 533 534 534 536

NetBIOS NetBIOS Namen NetBIOS-Namen: 16 Zeichen vs. 32 Zeichen (CIFS) NetBIOS Namensdienste: Broadcasts/WINS NetBIOS Suchdienste NetBIOS Scope ID NetBIOS Nachrichtentypen NetBIOS Protokollvarianten NetBIOS-Bindungen

Inhaltsverzeichnis

21.1.9 21.2 21.3 21.4 21.5 21.5.1 21.5.2 21.5.3 21.5.4 21.5.5 21.5.6 21.5.7 21.5.8 21.6 21.6.1 21.6.2 21.6.3 21.6.4 21.6.5 21.6.6 21.6.7 21.6.8 21.6.9 21.6.10 21.6.11 21.7 21.7.1 21.7.2 21.7.3 21.7.4 21.7.5 21.7.6 21.7.7 21.7.8 21.7.9 21.8 21.8.1 21.8.2

19

NetBIOS in der WinNT Registry NetBEUI/NBF NWLink – NetBIOS über NetWare-IPX NetBT – NetBIOS over TCP/IP Suchdienst/Browser Varianten der NetBIOS Namenstabellen Der Hauptsuchdienst/Master Browser Je NetBIOS-Transport ein Suchdienst Reihenfolge der Protokollbindungen zählt Viele Suchdienst-Server/Sicherungssuchdienst Suchdienstwahl: Wer ist Master Browser? Namens-Datagramme via UDP Port 137 »MSBROWSE«-Datagramme an UDP Port 138 WINS WINS statt Broadcasts NetBIOS-Registration am WINS-Server Der WINS-Server kennt alle NetBIOS-Ressourcen Mehrere WINS-Server/Replikationen Voraussetzungen für erfolgreichen WINS-Einsatz Der WINS Node Type/Knoten-Typ WINS-Registry-Einträge beim Client Bekannte WINS-Fehler WINS-Knoten-Typ stimmt nicht WINS-Server mit zerstörten Tabellen WINS und DNS: Siamesische Zwillinge DHCP DHCP-Optionen für WINS: Die sieben Todsünden DHCP-Fehler Nr. 1: IP Endadresse = 255!? DHCP-Fehler Nr. 2: Knoten-Typ = 0x00 DHCP-Fehler Nr. 3: Kein Standardwert DHCP-Fehler Nr. 4: 0x44 – ja/0x046 – nein!? DHCP-Fehler Nr. 5: Lokale WINS-Server angeben DHCP-Fehler Nr. 6: LANs ohne WINS-Server!? DHCP-Fehler Nr. 7: Knoten-Typ 0x08 oder 0x00!? DHCP-Fehler Nr. 8: Server-Standort!? SMB/CIFS Client-Server-Protokoll SMB, NFS, CIFS

538 539 540 542 544 545 546 548 548 550 551 551 552 552 552 554 554 555 556 557 559 559 559 559 560 560 560 560 561 562 562 564 564 564 564 565 565 566

20

Inhaltsverzeichnis

21.8.3 21.8.4 21.8.5 21.8.6 21.8.7 21.9 21.9.1 21.9.2 21.10 21.10.1 21.10.2 21.10.3 21.11 21.12 Kapitel 22

Fehler im Umfeld von SMB Fehler: Loops in Dateizugriffen SMB/NCP – doppelter Redirector SMB Write-Befehle mit 0 Bytes SMB File Handle ist falsch/0xFFFF WinNT Server hat lange Antwortzeiten Speicherverwaltung bei WinNT Server Memory-Tuning und Speed-Up WinNT: Infektionen & Wilderei PrintServer trieb WinNT in den Wahnsinn WinNT kennt DNS-Namen und fragt sie alle ab ... RUMBA-Zugriffe auf Non-Rumba-PC Windows-Tools zur Netzwerkdiagnose Registry-Analyse mit RegCheck

566 566 567 567 568 568 568 568 569 569 569 570 571 573

Windows-Tools

581

22.1 22.2 22.3 22.4 22.5 22.6 22.7 22.8 22.9 22.10 22.11 22.12 22.13 22.13.1 22.13.2 22.13.3 22.13.4 22.13.5 22.13.6 22.13.7 22.13.8 22.13.9

582 583 584 584 585 585 586 586 587 591 592 595 596 596 596 597 597 598 599 600 601 602

arp browstat browmon finger hostname ipconfig lpq lpr net nbtstat netstat nslookup ping ping -a ~ Namensauflösung ping -t ~ Endloslauf ping -n ~ Begrenzte Anzahl ping -l ~ Einstellung der Paketlänge ping -f ~ Fragmentierungstest ping -t ~ Hop Credit: TTL ping -v ~ IP Type of Service (ToS) ping -s ~ IP Option: Time Stamp ping -r ~ IP Option: Record Route

Inhaltsverzeichnis

Kapitel 23

Anhang A

21

22.13.10ping -j ~ IP Option: Loose Source Route 22.13.11ping -k ~ IP Option: Strict Source Route 22.13.12ping -w ~ Wartezeit bis zum Pong 22.13.13Ping mit Zielliste 22.13.14ping mit kombinierten Parametern 22.14 route 22.15 tracert

602 602 603 603 604 604 605

Ausblick: Windows 2000

609

23.1 23.2 23.3 23.4 23.5 23.6 23.7 23.8 23.9 23.10 23.11 23.12 23.13 23.14 23.15

610 611 611 612 612 612 612 613 613 614 614 614 615 615 616

Domains, Domain Tree, Active Directory WINS wird ersetzt durch DDNS Lightweight Directory Access Protocol Virtuelle Unternehmensnetze via Internet Verschlüsselung (A): Kerberos Verschlüsselung (B): EFS PDC und BDC werden abgelöst Replikationen / Partitionen Vertrauensstellungen Mobile Computing / Follow Me IntelliMirror Migration und Integration Mixed Mode Ausblick Messtechnik und Windows 2000

Die Registry von Windows NT

617

A.1 A.2 A.3 A.4 A.5 A.6 A.7 A.8 A.9 A.10 A.11 A.12

620 626 627 629 632 644 654 657 661 663 667 671

NetRules User Restrictions Service Provider / Name Space Provider TCP/IP Service Provider (WinSock) TCP/IP-Adapterparameter TCP/IP WinSock – AfD AppleTalk-Adapterparameter Browser / Suchdienst DHCP-Client DHCP Server DLC-Adapterparameter DNS

22

Inhaltsverzeichnis

A.13 A.14 A.15 A.16 A.17 A.18 A.19 A.20 A.21 A.22 A.23 A.24 A.25 A.26 A.27 A.28 A.29 Anhang B

DNS Zones InetInfo IP RIP LanMan Server MUP – Multiple UNC Provider NBF – NetBEUI Transport Frames NetBT – NetBIOS over TCP/IP NetBT-Adapter-Parameter NetLogon NwLnkIpx – NetWare Link IPX NwlnkNb – Novell NetBIOS Streams TCP/IP-Parameter TCP/IP Persistent Routes TCP/IP WinSock W3SVC – WWW Servivces WinSock

686 690 701 709 710 711 729 742 744 751 757 760 761 778 779 781 795

Produktbeschreibungen der wichtigsten Software-Analyzer

797

B.1 B.2 B.3 B.4 B.5

798 804 807 809 812

Observer (Network Instruments) EtherPeek (WildPackets) Surveyor (Shomiti) LANdecoder32 (Triticom) CNA Pro LAN-Fox (Chevin)

Stichwortverzeichnis

817

Vorwort

24

Vorwort

Windows-Rechner tun nicht immer das, was der Anwender oder Sysop will. Oft tun sie sogar Dinge, die ihnen strikt untersagt wurden: •

WinNT-Server senden IP-Broadcasts, ohne dass Sie dies gewusst hätten;

•

WinNT-Clients suchen im Internet nach Rechnern Ihrer Firma;

•

WinNT-Rechner halten Internet-Router für WINS-Server und versuchen daher, dort draußen im Internet Namensauflösungen zu betreiben;

•

WINS-Rechner benutzen DNS, obwohl Sie DNS »disabled« hatten;

•

Windows-Treiber missachten alle Regeln der »TCP Sliding Window Flow Control« und sorgen dafür, dass Ihre Windows Terminal Server (WTS) extrem lange Antwortzeiten haben.

Nicht, dass Windows ein schlechtes Betriebssystem wäre. Nur leider bekommen Sie das System das eine oder andere Mal nicht in den Griff. Und jetzt? Jetzt müssen Sie handlungsfähig sein. Und dies setzt zwei Dinge voraus: •

profunde Kenntnisse über WinNT, Registry und Datenkommunikation

•

profunde Kenntnisse über LAN/WAN Protokollanalyse

Dieses Buch soll Ihnen beides vermitteln: 1. Das Wissen um die Eigenheiten von Windows NT, die Merkwürdigkeiten und Heimlichkeiten der Windows Registry – über 300 Registry-Parameter zur Datenkommunikation sind in diesem Buch zu diesem Zweck dokumentiert. 2. Das Wissen um die Herangehensweise mit einem LAN-Analysator. Denn nur die Daten auf der Leitung bringen die Wahrheit ans Licht. Die Windows-Systemsteuerung »Netzwerk« gleicht manches Mal den Dörfern des berühmten Herrn Potemkin: schöne Fassade. Nicht alles, was die Datenkommunikation über Registry-Parameter steuert, erscheint in der Systemsteuerung. Und nicht alles, was Sie in der Systemsteuerung eintragen, hat den gewünschten Erfolg, da die Gesamtheit aller Registry-Einträge etwas ganz anderes bewirken kann als das, was Ihnen bei der Konfiguration via Systemsteuerung vorschwebte. Dieses Buch unternimmt erstmals den Versuch, Ihnen Wissen und Wahrheit über Windows NT im Bereich der Kommunikation zu vermitteln. Die Beilage-CD-ROM enthält zusätzliche Dokumentationen, Tools und DemoSoftware, um Ihnen den Zugang zur WinNT- bzw. LAN-Analyse zu erleichtern. Frank R. Walther [email protected] Synapse: Networks / Bonn

Kapitel 1 Das Werkzeug 1.1 1.2 1.3 1.4

Kriterien für LAN-Analysatoren Grundfunktionen Geräteklassen Fazit

26 27 52 60

26

Kriterien für LAN-Analysatoren

Dieser Abschnitt stellt eine Einführung dar in die Welt der Netzwerk-Analysatoren (LAN-Analysatoren, Protokoll-Analysatoren, Netzwerk-Tester). In mehreren Schritten sollen die Grundlagen geklärt werden, um dem Leser eine Entscheidungshilfe bei Beschaffung und Anwendung der Messgeräte zu geben.

1.1

Kriterien für LAN-Analysatoren Zunächst einmal muss klargestellt werden, dass hier nur LAN-Analysatoren berücksichtigt werden – nicht dagegen WAN-Tester (ISDN, X.25 etc.). Dies hängt mit der Art der Datenübertragung zusammen: Im LAN sind selbstständige und geschlossene Daten-Pakete unterwegs, während im WAN die Daten durch geschaltete Leitungen (switched circuits/Wählleitungen) laufen, die anderen technischen Prinzipien folgen als die herkömmlichen LANs. Aufgrund der LAN-typischen Übertragungsart in Daten-Paketen nennt man LAN-Analysatoren daher auch Packet Analyzer. Daten-Pakete (Packets) werden auch Frames genannt (Daten-Rahmen, DatenBlöcke), da auf der physikalischen Ebene (engl. »MAC Layer«) die Daten tatsächlich mit einem Kopf- und Schlussteil (header, trailer) eingerahmt werden. Das englische Wort »Frame« bedeutet nichts weiter als »Rahmen«. Die Familie der LAN-Analysatoren unterteilt sich begrifflich in verschiedene Varianten, die hier vorgestellt und erklärt werden sollen: •

Local Analyzer <> Remote Analyzer

•

Hardware-Analyzer <> Software-Analyzer

•

Hand-held Analyzer <> PC-Analyzer

•

Echtzeit-Analyzer <> Nicht-Echtzeit-Analyzer

•

Online-Analyzer <> Offline-Analyzer

•

Dual Port Analyzer <> Single Port Analyzer

•

External Analyzer <> Internal/built-in Analyzer

•

Active Analyzer <> Passive Analyzer

Was hinter diesen Begriffspaaren steckt, wird im folgenden Text ausführlich dargestellt. Zunächst aber werden die wichtigsten Grundfunktionen eines LAN-Analysators besprochen: •

Bedienbarkeit

•

Hardware-Nähe

Kapitel 1 • Das Werkzeug

•

Promiscuous Mode

•

Frame Capturing

•

Filtering

•

Auto-Learning

•

Experten-Diagnose

•

Protocol Decoding

27

Erst aus der Kenntnis der Grundfunktionen ergibt sich, welcher Bedarf hinsichtlich eines LAN-Analysators im jeweiligen Fall tatsächlich gegeben ist bzw. welche Funktionalität wann gefragt ist.

1.2

Grundfunktionen

1.2.1

Bedienbarkeit und Training Häufig werden Analyzer angeschafft, von denen sich die Verantwortlichen Wunder-weiß-was versprechen, weil sie Tausend-und-drei Funktionen bieten – die aber so kompliziert zu bedienen sind, dass sich kaum ein Mitarbeiter findet, der damit freiwillig arbeitet; und wenn sich jemand findet, so hat er wenige Wochen nach der Produktschulung schon wieder (fast) alles vergessen, weil es eben so kompliziert ist. Auch hilft es wenig, wenn wegen einer unverständlichen Bedienerführung am Ende nur ein einziger Mitarbeiter in der Lage ist, den Analyzer zu bedienen: Denn dann ist bei Urlaub, Krankheit etc. der Analyzer nichts mehr wert, weil ihn kein Zweiter mehr bedienen kann. Damit aber ist die Verfügbarkeit des Dienstes »Fehler-Diagnose« bzw. »LANAnalyse« gleich Null – und der große, teure Analyzer ist nichts anderes als ein Alibi. Weiterhin ist es eine falsche Annahme, dass der Analyzer nur bei auftretenden Fehlern einzusetzen wäre. Richtig ist, dass Messtechnik ständig eingesetzt werden muss, schon allein darum, weil laufende Statistiken wichtig sind, aber auch, weil ein ständig verbessertes Systemverständnis hilft, erst gar keine großen Fehler auftreten zu lassen. Es müssen also ständig mehrere Mitarbeiter mit Messtechnik arbeiten – dann aber kann eine extrem schwierige Bedienung nicht mehr akzeptiert werden, weil die hierfür notwendige Spezialisierung bei einer Vielzahl von Nutzern kaum noch erreicht werden dürfte. Der Autor hat mehrfach große Industrieunternehmungen bei Netzwerk-Crashes vor (weiteren) Verlusten im sechs- bis siebenstelligen DM-Bereich bewahrt;

28

Grundfunktionen

einige der größten DV-Dienstleister Deutschlands sind seine Kunden; und er wird meistens erst dann gerufen, wenn alle anderen schon vor ihm da waren (insofern diese als Lieferanten bzw. fest vertraglich gebundene Dienstleister als Erste gerufen werden); und die Fälle werden sämtlich mit einem »kleinen« Analyzer im Preisbereich von ca. 6.000 DM gelöst (LANdecoder32/Triticom, USA). Zuvor haben sich manches Mal andere Dienstleister mit Analyzern versucht, die mehrere Zehntausend DM teuer waren, und gefunden haben sie oft schlicht – gar nichts. Wie kommt es zu solchen Fehlleistungen und wie kommt es zu den damit verbundenen Ausfallkosten? 1. Die Bediener haben zu wenige Kenntnisse bzw. zu wenig Übung. 2. Sie kommen zu selten mit ihrem Analyzer zum Kunden. So kennt der Bediener weder das Netz, das er kurieren soll, noch den Analyzer richtig. Grund: Der Kunde ruft nur an, wenn es richtig »kracht«. Laufende Überwachung würde ja extra kosten, und Kosten sollen vermieden werden. Wartungsverträge, die laufende Messungen beinhalten, werden eher selten abgeschlossen. 3. Protokollanalyse verlangt nicht nur Übung, sondern auch erhebliche Kenntnisse von Rechnertechnik, Betriebssystemen, Kommunikationsprotokollen; und wenn der Bediener dann noch einen Analyzer hat, der ihm das Denken abnimmt (oder nur so tut, als ob), dann kann der Bediener in schwierigen Fällen selber nichts mehr beitragen und bleibt dem Funktionsumfang des Analyzers ausgeliefert – und das eben reicht nicht. Ein Analyzer muss den Analysten lernen lassen, muss ihn seine Ideen anwenden lassen; wenn ein Analyzer den Analysten zu wenig teilhaben bzw. lernen lässt, was er an Arbeitsweise und Wechselwirkung der Protokolle wissen muss, so ist das der falsche Analyzer. 4. Alles zusammen führt beim echten Crash zu einer simplen Verkettung unglücklicher Umstände: Der Analyst ist nervös, weil er zu wenig Übung und zu wenig Kenntnisse hat; die Vorgesetzten machen zusätzlich Druck, weil die Ausfallkosten so hoch sind; Dokumentationen liegen nicht vor oder sind unvollständig; und so steht unser Mann auf verlorenem Posten, muss aber für alle Fehlentscheidungen herhalten, die andere für ihn getroffen haben. 5. In einem solchen Szenario ist am Ende keiner mehr handlungsfähig. Der Crash ist unaufhaltsam. Wenn in einer Werkshalle die Fließbänder stillstehen und gerade Millionenverluste auflaufen, kann es doch wohl kaum »normal« sein, dass der Bediener des Analyzers erst noch nach dem Handbuch suchen muss, um nach einem bestimmten Filter zu suchen (den er dann vermutlich doch nicht setzen kann!)... und dennoch wird oft genau so gearbeitet. Bei schwierigen Fehlern ist immer noch der Mensch die Quelle des Lösungswissens; um dieses Wissen aufzubauen, benötigt man einen möglichst informativen

Kapitel 1 • Das Werkzeug

29

Analyzer; und um dieses Wissen anwendbar zu machen, benötigt man einen möglichst einfach zu bedienenden Analyzer; um Sicherheit in der Handhabung zu erlangen, braucht man zudem ständiges Training. Schon an dieser Bedingung scheitern die meisten Produkte bzw. scheitert ihr wirkungsvoller Einsatz.

1.2.2

Hardware-Nähe Je schneller die LANs werden, umso schneller müssen die Analyzer sein. Jeder Analyzer hat zur Verarbeitung eines jeden eingehenden LAN-Frames nur Zeit bis zum nächsten, darauf folgenden Frame. Schon 10-Mbps-Ethernet kann es auf bis zu 14.400 Frames pro Sekunde bringen; schon dieser »alten« LAN-Variante ist über normale Software-Lösungen kaum beizukommen, wenn das Netz unter starker Last steht. Analyzer können hinsichtlich ihrer Leistungsfähigkeit wie folgt eingeteilt werden: 1. Am leistungsfähigsten sind Analyzer, die als LAN-Adapter Sonderanfertigungen mit zusätzlichen On-Board-Prozessoren und On-Board-Memory verwenden, so genannte Hardware-Analyzer; diese sind jedoch sehr teuer (bis 100.000 DM), und einige Fabrikate wurden in der Vergangenheit bereits wegen zu geringer Verkaufszahlen vom Markt genommen. Früher wurden HardwareAnalyzer unter DOS betrieben; heute sind die Produkte unter Windows programmiert. 2. Danach folgen DOS-Analyzer, die in Assembler-Code geschrieben sind und die direkten Zugriff auf die Adapter-Karte haben; nach Kenntnis des Autors gibt es nur noch ein einziges solches Produkt (LANdecoder/DOS, Triticom), und auch hier ist das Ende in Sicht. Jüngste Tests haben bewiesen, dass dieser spezielle DOS-Analyzer mit seinem Assembler-Code auf einem 486-DX-66 auf einem 16-Mbps Token-Ring verlustfrei unter 98% Ringlast mit einer speziellen, alten Thomas-Conrad-Karte sämtliche Datenpakete aufnehmen konnte, während der über die NDISSchnittstelle arbeitende SnifferPRO auf einem Pentium mit 350 MHz und 128 MB Hauptspeicher rund 20% Paketverlust aufwies. Dies macht nachdenklich angesichts der immer stärkeren Aufrüstung in der PC-Technik. Erst nach den Hardware- und DOS-Analyzern folgen Windows- bzw. SoftwareAnalyzer in zwei Klassen: 3. Zunächst solche, die ohne die gängigen Software-Adaptertreiber (ohne NDIS, ODI) unmittelbar bzw. über spezielle Sondertreiber auf die Hardware des LAN-Adapters zugreifen (über sog. »direct drivers«).

30

Grundfunktionen

4. Danach folgen mit großem Abstand und mit extremem Leistungsverlust die über NDIS, ODI etc. arbeitenden Windows-Analyzer (z.B. LANalyzer for Windows/Novell). Die Wahl des Produktes hängt davon ab, was man tun will: Ist »harte« Analyse gefragt, bei der man sich keinerlei Datenverlust erlauben kann, so sind nur Analyzer der Kategorien (1) und (3) tauglich. Ist mehr »weiche« Statistik gefragt, bei der eine gewisse Rate an Datenverlust durchaus hingenommen werden kann, sind auch Geräte der Kategorie (4) tauglich. Die im Folgenden geschilderten Grundfunktionen hängen stark von der Hardware-Nähe ab.

1.2.3

Promiscuous Mode Für jeden Analyzer ist Bedingung, dass sein LAN-Adapter den sog. »Promiscuous Mode« unterstützt. In der Sozialwissenschaft bedeutet Promiskuität so viel wie »fremdgehen«, und das ist auch hier gemeint: Im Promiscuous Mode liest ein LAN-Adapter nicht nur die an ihn adressierten Pakete mit, sondern schlicht alles, also auch Fremddaten, die an Dritte adressiert sind und die normal übergangen würden. Nicht jeder LAN-Adapter unterstützt den für die Messung notwendigen Promiscuous Mode, und falls doch, kann es sein, dass der darüber arbeitende Adaptertreiber diese Fähigkeit nicht aufweist. In diesem Falle muss der Hersteller gefragt werden, ob ein solcher Treiber nachträglich verfügbar ist. Das ist durchaus oft der Fall: Die Kundschaft wünscht nicht, dass standardmäßig alle Rechner auf allen Arbeitsplätzen analysetauglich sind; das würde die Datensicherheit zu sehr beeinträchtigen. Also liefern die Hersteller überwiegend Treiber aus, die keine echte Analyse zulassen. Auf Wunsch aber sind die erforderlichen Treiber zur Analyse doch oft erhältlich. Es gibt in zweierlei Hinsicht Zwitter in Bezug auf mangelnde Unterstützung des Promiscuous Mode : 1. Der LAN-Adapter unterstützt den Promiscuous Mode, der Treiber jedoch nicht – oder umgekehrt. 2. Beide unterstützen zwar den Promiscuous Mode, aber nur unvollständig. Ein Beispiel für den Fall (2): Die Ethernet-Adapter der 3COM-Serie 3C509 lesen zwar Fremddaten mit, unterdrücken aber beschädigte Frames – mit dem kuriosen Ergebnis, dass die darüber laufende Analyse-Software keine Ethernet-Kollisionen zu sehen bekommt, was den am Bildschirm sitzenden Mitarbeiter zu dem Fehlschluss führt, sein Ethernet arbeite kollisionsfrei.

Kapitel 1 • Das Werkzeug

31

Entsprechende Informationsverluste kann es auch bei Token-Ring-Adaptern geben; aus Sicherheitsgründen gibt es sogar Token-Ring-Adapter, die jegliche Form des Analysezugriffs grundsätzlich schon in der Hardware unterbinden. Da Token-Ring traditionell bei Banken und Versicherungen stark vertreten war bzw. ist, hat hier die entsprechende Nachfrage zu diesem Angebot der Hersteller geführt. IBM hatte seinerzeit dann eigens zur Analyse den sog. Trace And Performance Adapter (TAP) entwickelt. Weiterhin gehört es zu den vom IEEE definierten Grundfunktionen der LANAdapter, dass schon in der Hardware Fehlererkennung betrieben wird und die entsprechenden Zähler geführt werden. Nicht die Analyse-Software »erkennt« z.B. einen CRC Error (Prüfsummen-Fehler); dies tut vielmehr der LAN-Adapter, und der Zählerstand wird vom Analyzer lediglich abgefragt. Der Analyzer ist also vollständig davon abhängig, dass diese Funktionen in der Hardware des LANAdapters korrekt laufen. Hier gibt es zwischen den Herstellern erhebliche Unterschiede in der Leistungsfähigkeit und Zuverlässigkeit; hierauf wird im Abschnitt zur Ethernet-Analyse noch weiter eingegangen.

1.2.4

Monitoring vs. Analyse Der LAN-Analysator unterscheidet sich vom LAN-Monitor dadurch, dass er nicht nur Statistik betreibt, sondern die LAN-Frames zudem einliest und einer weiteren Auswertung zugänglich macht. Grundsätzlich also wird wie folgt unterschieden: 1. LAN-Monitor: laufende Statistik online. 2. LAN-Analysator: laufende Statistik online sowie zusätzliche Aufnahme der LAN-Frames zur späteren Auswertung. Die Aufnahme der LAN-Frames wird im Englischen als Capturing bezeichnet (engl. für »einfangen«). Hierbei ist schon auf mögliche Schwachstellen zu achten:

1.2.5

Capturing Die Leistungsfähigkeit eines LAN-Analysators hängt wesentlich davon ab, dass das Capturing so wenig Prozessorzeit verbraucht wie irgend möglich. Je mehr Zeit für Capturing verbraucht wird, umso weniger Zeit steht für die eigentliche Analyse zur Verfügung. Und mehr noch: Kommen die LAN-Frames nicht schnellstmöglich in den PCSpeicher, so gehen Datenpakete verloren; dies endet oft in der Meldung: »Lost Frames«. Das bedeutet: Wenn die Eingangspuffer des LAN-Adapters nicht durch die höheren Instanzen sofort geleert werden, gerät der LAN-Adapter in einen Annahmestau (»Congestion« oder »Buffer Overflow«), und bis zur Beendigung der Staubedingung gehen alle weiteren LAN-Frames verloren, weil sie nicht mehr angenommen werden können.

32

Grundfunktionen

Bei einem LAN-Monitor ist diese Schwäche nicht in jedem Fall bedenklich, da die Statistiken dadurch nicht unbedingt erheblich verfälscht werden müssen. Bei einem LAN-Analysator jedoch kann es auf jedes einzelne Datenpaket ankommen. Ja, mehr noch: Oft treten Fehler im LAN genau dann auf, wenn das LAN bei extremen Datenraten unter Höchstlast steht – und wenn just in diesem Moment Frames für den LAN-Analysator nicht mehr sichtbar werden, weil sie vom LANAdapter verworfen werden, kann die ganze Messung vergebens sein. Diese zentrale Schwäche ist leider bei vielen LAN-Analysatoren gegeben, insofern sie Software-Analyzer sind, die über herkömmliche LAN-Adapter und ihre Treiber (NDIS, ODI) arbeiten. Daher ist es unbedingt empfehlenswert, entweder Hardware-Analyzer zu nehmen oder die wenigen Software-Analyzer, die zwar über einen handelsüblichen LAN-Adapter arbeiten, aber nicht über NDIS/ODITreiber, sondern über Direktzugriff auf den Hardware-Chipsatz des Adapters. Der Zeitverlust durch den Einsatz von Software-Treibern (NDIS, ODI) hat regelmäßig zur Folge, dass wahlweise eine von zwei Schwächen gegeben ist: 1. Es gibt zu wenig Online-Auswertung, weil die Programmierer die Schwäche kennen und darauf Rücksicht nehmen – was zum Zwang führt, sich umso mehr später ins Protocol Decoding (s.u.) zu begeben, was praktisch immer einen immensen Zeitverlust bedeutet. 2. Es gibt trotz der Schwäche reichliche Online-Statistik, dann aber um den Preis großen Datenverlustes, weil die Prozessorzeit einfach nicht ausreicht, beides zu leisten: Vollständige Statistik sowie Aufnahme aller Pakete. Dies führt zu der Frage: Welche Information ist online zwingend erforderlich? Auf was könnte man verzichten, wenn man vorrangig an der Protokollanalyse interessiert ist, also am Aufspüren versteckter Fehler? Zu den Informationen, die online gegeben sein müssen, gehören: 1. Darstellung aller LAN-typischen Fehler: Prüfsummenfehler, Längenfehler etc., bei Token-Ring zusätzlich die Darstellung des MAC-Protokolls. 2. Auflösung aller Datenbeziehungen in sog. Conversation Pairs, also Kommunikationspaare (statt einer einfachen Liste nur einzelner Stationen). 3. Die Conversation Pairs müssen auf verschiedenen Adressierungsebenen angezeigt werden. Die wichtigsten sind: – MAC-Adressen (Adresse der LAN-Adapter) – IP-Adressen – TCP/UDP-Ports

Kapitel 1 • Das Werkzeug

33

4. Je Conversation Pair (das ist: »Station-A von/zu Station-B«) die Angabe von – [Frames A>B] + [Frames AB] + [Octetts AB] + [Errors A
Abb. 1.1: Conversation Pairs beim LANdecoder32

Viele Analyzer zeigen nicht Paarbeziehungen an, sondern jede Station einzeln; damit aber lässt sich online der Status einer Beziehung nicht mehr ablesen, da sich nicht mehr sagen lässt, an wen eine Station Daten sendet und von wem sie Daten empfängt und auf welche Beziehung(en) sich welche Fehler verteilen. Diese Kriterien werden nur noch von wenigen Analyzern befriedigend erfüllt.

1.2.6

Filtering Neben der puren Geschwindigkeit beim Capturing ist unbedingt auf die Fähigkeit beim Filtering zu achten – und zwar dem Online-Filtering, nicht dem nachträglichen Offline-Filtering.

34

Grundfunktionen

Es ist insbesondere bei den schwierigen Fehlern extrem wichtig, dass über das Setzen von Filtern genau eingestellt werden kann, welche LAN-Frames vom Analysator eingelesen werden sollen und welche nicht. Gründe: Oft haben Analysatoren nur eine begrenzte Aufnahmekapazität ihres Hauptspeichers (nämlich genau dann, wenn sie die Messdaten nicht laufend auf die Festplatte schreiben können). Der Aufnahmekapazität entspricht jedoch die mögliche Messdauer, d.h.: Das Zeitfenster kann nicht größer sein als die Aufnahmekapazität. Und selbst dann, wenn die Fähigkeit zum Wegschreiben auf die Festplatte besteht, muss gesehen werden, dass während des Wegschreibens in eine Datei die Datenaufnahme beeinträchtigt ist oder sogar ruht – was die Messung wieder vorübergehend unzuverlässig macht. Es ist also von äußerster Wichtigkeit, dass möglichst alle LAN-Frames, die zur Diagnose des Fehlers von Belang sind, in einen möglichst lange vorhaltenden Hauptspeicher gelangen. Insbesondere bei nur sporadisch auftretenden Fehlern ergibt sich die Notwendigkeit von Langzeitmessungen, bei denen besonders große Datenmengen anfallen können – und schnell kann der Aufnahmespeicher des Analysators voll sein. Bei einem stark ausgelasteten Ethernet mit »nur« 10 Mbps können schon in nur 30 Sekunden 16 Mbyte des Hauptspeichers voll sein! Ein Zeitfenster von nur 30 Sekunden aber ist viel zu klein, um zuverlässig Fehlersuche betreiben zu können. Es müssen also unter Umständen Filter gesetzt werden, die alle Daten außen vor halten, die nicht benötigt werden. Tatsächlich wird über Filter genau definiert, welchen Inhalt LAN-Frames haben müssen, um aufgenommen zu werden. Je genauer diese Filter definiert werden können, umso weniger »Müll« wird aufgenommen – und umso länger ist das Zeitfenster (= die Messdauer), und umso größer ist die Aussicht, das Fehlerereignis auch tatsächlich »im Kasten« zu haben. Viele LAN-Analysatoren, die heutzutage erhältlich sind, haben nur mäßige Filterfähigkeiten, manche Analyzer sind geradezu völlig unbrauchbar. Es gibt aus Sicht des Autors vielleicht gerade mal eine Handvoll Fabrikate, die wirklich gutes Filtering bieten. Was ist das: gutes Filtering? Gutes Filtering besteht (a) aus der Möglichkeit, nicht nur auf Protokolle, sondern auf Inhalte und Ereignisse zu filtern, (b) aus einer Bedienerführung, die mit wenigen Mausklicks das gewünschte Ergebnis liefert. Ein Beispiel für einfache Navigation sei hier gegeben: Es wird ein bestimmtes IP-Paket untersucht. Es ist der Verdacht gegeben, dass dieses IP-Paket doppelt auf der Leitung gewesen sein könnte. Ein einfacher Weg, das herauszufinden, ist, nach allen IP-Paketen zu filtern, welche dieselbe Paket-ID (Fragment ID) tragen. Das folgende Beispiel zeigt, wie schlicht Folgendes getan wird:

Kapitel 1 • Das Werkzeug

35

•

Es wird die Zeile markiert, welche die IP Fragment ID enthält; gleichzeitig wird automatisch unten im sog. Hex-Dump der Hex-Wert markiert.

•

Es wird die rechte Maustaste gedrückt und im Popup-Menü die Funktion HexFilter gewählt.

•

Es wird bestätigt, dass nach dem markierten Hex-Ausdruck gesucht werden soll.

•

Danach wird ersichtlich, dass das IP-Paket nicht doppelt war, da in der gefilterten Paketliste (im Hintergrund) nur das eine aktuelle Paket übrig blieb.

Abb. 1.2: Eine Stelle im aktuellen Paket wird markiert.

Dieser Vorgang kostet nur wenige Sekunden und ist äußerst wirkungsvoll. Beliebige Merkmale beliebiger Pakete können zum Gegenstand beliebiger Filter gemacht werden – das ist gerade zum Aufspüren seltener, versteckter Fehler sehr wichtig. Neben dieser einfachen Art, aus dem Zusammenhang heraus schnell und unkompliziert wirksame Filter zu setzen, sollte die Fähigkeit gegeben sein, komplexere Filter zu setzen und dauerhaft abzuspeichern, um sie jederzeit wieder aktivieren zu können.

36

Grundfunktionen

Abb. 1.3: Mit Mausklick rechts wird die Funktion »Hex Pattern (Filter)« aufgerufen.

Abb. 1.4: Es folgt eine Abfrage nach dem Offset (der Byte-Position) der gesuchten Hex-Folge.

Im folgenden Beispiel soll in einem Token-Ring-Trace nach Fehlermeldungen gesucht werden, die von Token-Ring-Adaptern gesendet wurden. Hierzu wurde eine Filtermaske bereits früher abgespeichert; diese wird erneut eingeladen und der Filter wird aktiviert (siehe Abbildungen 1.7-1.11). Ansonsten ist wichtig, dass man schnell und unkompliziert die Protokolle herausfiltern kann, die dem Bearbeiter jeweils wichtig sind. Das kann etwa so aussehen (siehe Abbildungen 1.12 und 1.13):

Kapitel 1 • Das Werkzeug

Abb. 1.5: Die Offset-Abfrage auf dem Gesamtbildschirm.

Abb. 1.6: Das Ergebnis: Die Frame-Liste enthält nur noch die Treffer (hier: nur das aktuelle Paket entsprach dem Filter, wie die Angabe »1 of 1119 frames» rechts unten zeigt).

37

38

Grundfunktionen

Abb. 1.7: So sieht der Trace noch ohne Filter aus: Es sind alle Pakete zu sehen.

Abb. 1.8: Sodann wird die Filtermaske aufgerufen und dort »Load« gewählt.

Kapitel 1 • Das Werkzeug

39

Abb. 1.9: Aus den hinterlegten Filtern wird einer ausgewählt.

Abb. 1.10: Automatisch sind die Filterregeln in die Maske eingetragen worden.

Filter auf Protokolle zu setzen ist also wichtig und sehr hilfreich. Aber: Viele Analyzer bieten nur diese Filter auf Protokolle bzw. Protokollfamilien, also Filter auf »IP« oder »TCP« oder »IPX« oder »NetBIOS«. Das allein aber ist für die Praxis gänzlich ungenügend. Warum?

40

Grundfunktionen

Abb. 1.11: Das Ergebnis: Nur noch bestimmte Token-Ring-Frames sind in der FrameListe übrig geblieben.

Abb. 1.12: Es wird ein Doppelfilter auf zwei NetBIOS-Varianten gesetzt.

Kapitel 1 • Das Werkzeug

41

Abb. 1.13: Es bleiben nur noch Pakete mit NetBIOS in der Frame-Liste übrig.

Die meisten File Server arbeiten nur mit einem Protokoll (IP oder IPX) – und welchen Sinn hätte es, bei einem Unix-Server einen Filter auf »TCP/IP« zu setzen? Und: Die meisten Anwender-PCs arbeiten entweder über LLC/NetBEUI oder über TCP/IP oder über IPX/SPX. Hat nun ein Anwender Probleme, reicht es, einen Filter auf die MAC-Adresse seines LAN-Adapters zu setzen; selten ist es dann noch notwendig, hier zusätzlich nach Protokoll einzugrenzen. Das, was wirklich zählt, ist das Herausfiltern bestimmter Ereignisse innerhalb eines Protokolls. Protokollfilter sind oft erst dann richtig hilfreich, wenn man eine ganze Protokollgruppe einkreisen will, etwa »NFS« + »Port Map Protocol (PMAP)« + »MOUNT« und »RPC«, um damit bestimmte Datei- und Authentisierungsoperationen besser nachvollziehen zu können. Aber selbst dann ergibt sich nach erster Erkundung schnell der Bedarf nach weiteren, auf Ereignisse oder Inhalte bezogenen Filtern.

42

Grundfunktionen

Hierzu zwei Beispiele: Erstes Beispiel: Ein Anwender klagt darüber, dass beim Laden eines bestimmten Applikationsmoduls der PC festhängt. Hypothetisch könnten hier die Gründe sein: 1. Zu wenig Hauptspeicher, und der Programmierer testet beim Laden von Modulen den verfügbaren Speicher zuvor nicht aus. 2. Die Zahl der gleichzeitig geöffneten Dateien ist zu groß (DOS/Win3x). 3. Im Programm-Modul ist ein Code-Fehler. 4. Benötigte Dateien werden nicht gefunden (und es gibt keine absichernde Prüfroutine im Programm-Code). 5. Temp-Dateien können nicht geschrieben werden. 6. Die Verbindung geht bei zu langen Ladezeiten verloren. 7. Der Server, auf den der Anwender zugreift, muss bei bestimmten ProgrammModulen seinerseits auf weitere Server zugreifen; der Zugriff auf einen dieser zusätzlichen Ressourcen-Server ist aber gestört, etwa wegen Fehlern in SQLQueries. Bei Fehlern wie bei (4) und (5) können seitens des File-Servers mangelnde Zugriffsrechte eine Rolle spielen, aber auch das tatsächliche Fehlen von Dateien. Sollte dies der Fall sein, gibt praktisch jeder File-Server Fehlermeldungen an den Client-PC zurück – Meldungen, die oft genug beim Client-PC nicht oder nur verfälscht auf dem Bildschirm ausgegeben werden. Bei Fehlern wie bei (6) sind die PC-Fehler-Meldungen für gewöhnlich sogar völlig missverständlich bzw. unbrauchbar. Zweites Beispiel: Mehrere Win95/WinNT-Arbeitsrechner arbeiten mit Daten, die auf einem UnixServer liegen. Sie greifen jedoch nicht selber unmittelbar auf den Unix-Host zu. Vielmehr korrespondieren sie via SMB-Protokoll mit einem speziellen WinNTServer, der als sog. NFS-Gateway arbeitet. Dieser WinNT-Server greift via IP-UDP-NFS auf den Unix-Host zu und präsentiert die dort gelesenen Daten via SMB den Client-PCs als scheinbare Daten (»Share«) des NT-Servers. Was nun, wenn hier ein Fehler auftritt? Dann reicht es nicht, die Paarbeziehung zwischen einem Win-Client und dem WinNT-Server zu überwachen – dann ginge verloren, was im Hintergrund der WinNT-Server mit dem Unix-Host an Daten wechselt. Es reichte auch nicht, nur SMB oder IP zu überwachen. Um alle Vorgänge, die beteiligt sind oder beteiligt sein könnten, zu überwachen, und um alle Fremddaten auszuschließen, sind teilweise komplexe Filter notwendig. Solche Fähigkeiten sind bei vielen Analyzern nicht vorhanden.

Kapitel 1 • Das Werkzeug

43

Fazit: Es wäre also wichtig, mit dem LAN-Analysator genau nach den Fehlermeldungen des File-Servers zu suchen sowie nach den Frames, mit denen eine verloren gegangene Verbindung wieder hergestellt werden soll, und dergleichen mehr. Hierzu aber muss der LAN-Analysator in der Lage sein, genau nach solchen Frames zu suchen – durch genau gesetzte Filter. Es gibt am Ende noch einen weiteren, wichtigen Grund für die Fähigkeit, exakte Filter zu setzen, nämlich: die Datenmenge kleinzuhalten. Wer soll denn – zumal unter extremem Zeit- und Erfolgsdruck!! – Zehntausende oder gar Hunderttausende von Frames durchsehen und verstehen können? Niemand kann das leisten. Gutes On-Line-Filtering ist ein absolutes K.O.-Kriterium bei der Beschaffung eines Analyzers. Da nur wenige Analyzer überhaupt gutes Filtering unterstützen, fallen bei ihnen auch dementsprechend große Mengen an Messdaten an; und deren Durchsicht setzt erhebliches Können des Bedieners und dazu unterstützende Funktionen der Software voraus. Daraus ergibt sich dann die Notwendigkeit, die Durchsicht und Auswertung zu automatisieren – und das Auswertungsmodul des Analyzers wird dann Expertendiagnose genannt. Bevor jedoch die Funktion der sog. Expertendiagnose erläutert wird, muss zum Thema Filtering eine wichtige Einschränkung gemacht werden.

1.2.7

Endlosaufzeichnungen Das zuvor Gesagte hinsichtlich der Notwendigkeit, Filter zu setzen, bedarf einer Voraussetzung, die problematisch ist, nämlich: dass der Analyst weiß, wonach er zu suchen hat. Damit aber kann sich die Katze in den Schwanz beißen: Wenn der Bediener des Analyzers sowieso schon weiß, wonach er zu suchen hat, ist der Fall sowieso schon halb geklärt, und der Rest ist reine Formsache! Oft aber ist es doch genau anders herum: In der Panik eines Netzwerk-Crashes geht alles durcheinander, wichtige Dokumentationen liegen nicht vor, jeder hat eine andere Idee, alle machen mit, keiner weiß, was genau läuft, und alle erschweren sich dadurch gegenseitig die Arbeit. Oder: Der externe Dienstleister (so ggf. der Autor selber) wird gerufen; dieser kennt weder das gegebene Netzwerk, noch die darin vorhandenen Konfigurationen, alle reden widersprüchlich auf ihn ein, verlassen kann er sich auf nichts, und im Zweifel wird er noch auf eine falsche Fährte gelockt.

44

Grundfunktionen

Hier hilft nur eines: radikal alles mitlesen, was auf der Leitung ist. Seriös gesprochen begründet sich das wie folgt: Dass eine Maschine im Zusammenhang A bestimmte Fehler macht, kann in Wechselwirkungen mit den Zusammenhängen B und C verquickt sein. Werden nun Filter gesetzt, die nur Zusammenhang A berücksichtigen, sieht man hinterher entweder nichts mehr, was Aufschluss bieten könnte, oder man sieht nur geringe Teile, also Ausschnitte, aus dem tatsächlichen Szenario. Zwei Beispiele sollen das verdeutlichen: 1. Bei einem Kunden stürzte mehrfach am Tag ein NetWare-Server ab. Der Kunde hatte bereits selber so ziemlich alles ausgewechselt, was an diesem Server auszuwechseln war: LAN-Adapter, Hauptspeicher, Treiber. Am Ende war die Festplatte (samt Controller) das einzige Bauteil, das nicht ausgewechselt worden war. Aber immer noch stürzte der Server ab. Eine Messung, bei der ein Filter auf die MAC-Adresse des Servers gesetzt worden war, ergab, dass der LAN-Adapter des Servers völlig deformierte Pakete sendete, die sämtlich die Endloszeichenkette »FreeFreeFreeFree...« enthielten. Der Kunde nahm daraufhin an, dass eben auch dieser Adapter defekt sei, und wollte schon wieder die Hardware austauschen. Wir hielten ihn davon ab und zeigten ihm die Ergebnisse einer Messung, die zuvor schon durchgeführt worden war – und zwar ohne Filter: Es zeigte sich, dass die Backbone-Switches massenhaft Pakete zerstörten, und das in einer Weise, die sie unleserlich machte. Es war immer nur eine Frage der Zeit, bis eines oder mehrere dieser Pakete durch puren Zufall beim NetWare-Server nicht verworfen, sondern als »normal« akzeptiert und verarbeitet wurden – mit der Folge, dass der NetWare-Server daraufhin abstürzte. Zwar war dies definitiv auch ein Fehler des NetWare-Servers, der defekte Pakete zuverlässig zu erkennen und zu verwerfen hatte; der eigentliche Auslöser aber waren defekte Pakete, die seitens des Switches auf die Leitung gebracht wurden. 2. Bei einem Kunden stürzten in unregelmäßigen Abständen immer mehrere Rechner gleichzeitig ab. Das Szenario lief jedes Mal gleich ab: Der Bildschirm der betroffenen Rechner schien sich von unten her mit Tinte zu füllen, denn Zeile für Zeile wurde der Monitor schwarz. Wurde das erkannt, bevor alles schwarz war, und wurde der Rechner jeweils noch schnell heruntergefahren und abgeschaltet, so konnte er danach wieder normal gestartet werden. Geschah dies nicht (etwa, weil der Anwender nicht am Arbeitsplatz war), so war hinterher das CMOS zerstört, und der Rechner konnte nicht ohne weitere Reparatur neu gestartet werden. Hier hätten Messungen mit Filtern nicht mehr geholfen: einerseits, weil beim Absturz mehrerer Rechner (die zudem ständig wechselten) kaum von vornherein geraten werden konnte, welche Gemeinsamkeit sie in diesem Absturz verband; zweitens, weil dieses Ereignis nur zweioder dreimal monatlich auftrat, also die Vorhersagbarkeit nicht gegeben war, und weil somit keinerlei Aufschluss gewonnen werden konnte, welche Filter

Kapitel 1 • Das Werkzeug

45

sinnvoll sein konnten. Am Ende von Dauermessungen stellte sich heraus, dass Backbone-Switches sporadisch LAN-Pakete vervielfältigten, teilweise um ein Tausendfaches; und wenn dies durch puren Zufall mit LAN-Broadcast-Paketen geschah, brachen einige LAN-Adapter bzw. das dahinter arbeitende PCSystem zusammen, weil die dadurch in extremer Zahl ausgelösten Interrupts durch die Hard- und Software des PCs nicht mehr handhabbar waren. In allen diesen Fällen konnte der Fehler nur erkannt werden, indem Endlosmessungen durchgeführt wurden. Dies aber setzt einen leistungsfähigen Analyzer voraus, der in der Lage ist, laufend die Messdaten auf die Festplatte zu schreiben. Der Autor verwendet hierzu den LANdecoder32 von Triticom, der in der aktuellen Version 3.1 bis zu 4 Gbyte Messdaten schreiben kann (255 Daten zu je max. 16 Mbyte), wobei wahlweise entweder bei Erreichen von 255 Dateien die Messung beendet (Langzeitmessung) oder aber weiter fortgeführt wird, indem die ältesten Dateien überschrieben werden (Endlosmessung). Arbeitet man auf diese Weise mit einer Endlosmessung, so braucht man nur noch die Messung zu stoppen, wenn das Fehlerereignis eingetreten ist – und dann kann man sicher sein, alle wichtigen Daten auch »gefangen« zu haben, was bei einer Messung mit Filtern eben nicht mehr der Fall wäre. Bei diesen Gelegenheiten nun aber fallen dermaßen gigantische Datenmengen an, dass man nur noch auf eines hoffen kann: Dass der genaue Zeitpunkt des Zusammenbruchs bekannt ist. Fehlt diese Auskunft, so steht man vor dem Problem, am Ende mehrere Gigabyte von Messdaten durchsehen zu müssen. Dieses ist ohne automatische Hilfe des Analyzers nicht mehr zu schaffen. Entsprechend ist die sog. Expertendiagnose von großer Bedeutung.

1.2.8

Expertendiagnose Es ist wie mit dem Taschenrechner: Denken kann er nicht, aber zählen kann er gut. Für das Expertensystem eines Analyzers heißt das: Wirklich begreifen kann es die Messdaten nicht, aber gängige Fehler kann es gut und schnell sichtbar machen. Bleibt nur die Frage: Was ist mit Fehlern, die nicht gängig sind? Für die Berechnung der mittleren Reisezeit einer Made im Apfel zum Mond und zurück hat kein Taschenrechner der Welt eine Formel – und für die wirklich schwer zu knackenden Fehler hat das beste Expertensystem eben bis heute kein Rezept.

46

Grundfunktionen

Um nicht missverstanden zu werden: intelligente, automatische Auswertung der Messdaten ist wichtig und hilfreich, oft unverzichtbar. Aber: Bei einigen Herstellern ist die Expertendiagnose schlicht eine Ersatzfunktion für den Mangel an intelligenten, umfassenden Filterfähigkeiten. Es ist gut, nach einem fein abgestimmten Capturing & Filtering auch noch eine Expertendiagnose zu haben – aber eben zusätzlich, nicht statt dessen. Bei manchen Herstellern jedoch sind die Schwächen im Filtering so extrem, dass über die Expertendiagnose keine rechte Freude aufkommen will. Was nutzt das schönste Expert-Tool, wenn das Fehlerereignis gar nicht im Trace (=in den Messdaten) enthalten ist? Ist die Datenmenge aber klein und enthält sie nur das, was gesucht ist, so ist die Expertendiagnose oft entbehrlich. Expertendiagnose ist grundsätzlich gut, um statistische Auffälligkeiten und Standardfehler zu entdecken. Solche Arbeiten noch per Hand zu erledigen, wäre müßig. So wäre es heute glatte Zeitverschwendung, nach doppelten IP-Adressen noch per Hand zu suchen. Fast jeder Analyzer bietet heute automatische Erkennung solcher einfachen Fehler.

Abb. 1.14: Automatische Analyse der IP-Adressen und IP-Wege

Kapitel 1 • Das Werkzeug

47

Abb. 1.15: Automatische Statistik der Protokollanteile

Expertendiagnose ist vor allem dann gut, wenn sie online stattfinden kann, d.h.: Wenn während der laufenden Messung schon Meldungen auf den Bildschirm kommen, mit denen Fehler gemeldet werden wie z.B. »Duplicate IP Address« oder »Lost Frames«. Insbesondere für Laien und externe Fremdkräfte sind solche Fähigkeiten nützlich und wichtig; sie gehen jedoch meistens zu Lasten der Filterfähigkeiten, die wiederum für den Analyseexperten vorrangig wichtig sind. Dieser Konflikt ist immer gegeben, da die Prozessorzeit in aller Regel begrenzt ist und nicht von allen Funktionen beliebig zugleich genutzt werden kann. (Siehe auch unten: »Auto-Learning«.) Bei alledem gilt jedoch: Wenn Netzwerkfehler wirklich schwer zu finden sind, hilft die Expertendiagnose meistens auch nicht mehr. Denn die Expertendiagnose kann nur so viel leisten, wie die Programmierer an Logik hineingelegt haben – und das ist eben das »Wissen« um Standardfehler. Was aber geschieht mit Fehlern, die praktisch einmalig sind (oder doch sehr selten), und die deswegen auch so schwer zu finden sind? Diese Fehler können über Expertendiagnose nicht gefunden werden; ihrer wird man nur Herr durch intelligentes Filtering und durch erstklassiges Protocol Decoding.

48

1.2.9

Grundfunktionen

Auto-Learning Für Außendiensttechniker, die in fremde LANs »sehen«, ist wichtig, dass sie sich schnell orientieren können: Welche Server gibt es, welche Router, welche Switches, welche SNMP/RMON-Komponenten? Welche Protokolle werden verwendet? Welche Topologie hat das Netzwerk? Wer spricht mit wem? Solche Fähigkeiten können als Teil von »Expertendiagnose« angesehen werden; sie können sowohl in LAN-Monitoren als auch in LAN-Analysatoren auftreten. Als »Auto-Learning« wird die Fähigkeit bezeichnet, dass die wichtigsten Fakten automatisch erkannt und zugeordnet werden: NetBIOS-Namen werden den entsprechenden MAC- und IP-Adressen zugeordnet; die Namen von File-Servern und Print-Servern werden erkannt und den entsprechenden MAC- und IP/IPXAdressen zugeordnet; die wichtigsten Router und ihre IP/IPX-Adressen werden erkannt und ihren DNS-Namen zugeordnet; und so weiter. Teilweise sind noch einige manuelle Eingriffe notwendig, um das alles arbeiten zu lassen; so muss oft noch die IP-Adresse des DNS-Servers angegeben werden, von dem die Rechnernamen bezogen werden können. Im Ganzen aber ist eine solche Funktion des »selbstständigen Lernens« wichtig und für den Bearbeiter sehr angenehm.

1.2.10 Protocol Decoding Das Missverhältnis zwischen Filtering und Expertendiagnose war schon als schwerer Mangel vieler Analyzer benannt worden. Die zweite große Schwachstelle vieler Produkte ist das Protocol Decoding. Unter Protocol Decoding wird die Darstellung und Erläuterung der einzelnen eingelesenen LAN-Frames verstanden. Für den Autor gibt es zur Zeit auf dem Markt in letzter Konsequenz nur einen oder zwei Analyzer, die das bieten, worauf es im Ernstfall ankommt: volle Darstellung, Übersicht, Auflösung bis ins letzte Bit, gutes Filtering. Andere wiederum teilen diese Meinung nicht und »schwören« auf andere Produkte. Ganz unabhängig davon, dass der Autor glaubt, gute Gründe für sein Urteil anführen zu können, ist doch eines unbestreitbar: Verschiedene Analyzer folgen verschiedenen Sichtweisen und Darstellungsformen; welche davon im Einzelfall geeignet sind, hängt vom aktuellen Netzwerk und seinen Problemen ab, von den Vorkenntnissen und dem Training des Analysten sowie schlicht dem »Look-And-Feel«, das sich aus allem ergibt. Bei allen persönlichen Neigungen jedoch lassen sich einige Kriterien herausarbeiten, die sicherlich als objektiv gegeben angesehen werden dürfen.

Kapitel 1 • Das Werkzeug

49

Übliche Schwachstellen im Protocol Decoding sind: •

Die Frame-Liste zeigt zu wenige Frames in der Übersicht an (zu große Zeichen, zu wenige Zeilen), weswegen längere Datendialoge praktisch kaum visuell nachvollziehbar sind. Abbildung 1.16 und Abbildung 1.17 zeigen den Unterschied: Erst in der zweiten Darstellung kann die Übersicht über einen längeren Vorgang gewonnen werden. Was allerdings hier schlicht durch Wechseln der Schriftgröße (Font) erreicht wurde (nämlich eine kleinere, engere Darstellung), ist bei manchen Produkten gar nicht möglich.

Abb. 1.16: Eine Frame-Liste, die kaum Übersicht gewährt.

•

Die Darstellung erfolgt im »Flattersatz«, bei dem alles linksbündig steht, also nicht gut geordnet. Schon allein die MAC-Adressen der beiden Zeilen Source Address und Destination Address erscheinen nicht genau untereinander, da die Worte »source« und »destination« nicht gleich lang sind. Solcherlei schlechte Optik lässt das Auge schnell ermüden, zumal dann, wenn man auf Verdacht nach Fehlern sucht und viele Frames durchblättern muss.

50

Grundfunktionen

Abb. 1.17: Eine Frame-Liste, die längere Vorgänge gut erfassen lässt.

•

Die Darstellung erfolgt in zu großen oder zu kleinen Zeichen; entweder passt zu wenig Information auf den Bildschirm bzw. in die Sichtfenster (s.u.), oder die Zeichen sind so klein, dass man sie nicht mehr lesen kann. Bei vielen Produkten ändert selbst die einstellbare Zeichengröße (Font) nichts am Ergebnis der Unleserlichkeit.

•

Der Anteil eines einzelnen Protokolls passt nicht ins Sichtfenster, und zum Einsehen der hinten (= unten) liegenden Protokollparameter muss im Sichtfenster geblättert (gescrollt) werden. Dies ist eine schiere Katastrophe, wenn eine Vielzahl von Frames durchgesehen werden muss und es mit dem Weiterblättern von Frame zu Frame nicht getan ist, weil man bei jedem einzelnen Frame dann noch im Sichtfenster zum gewünschten Parameter scrollen muss. In Abbildung 1.18 ist zu sehen, dass die Auflösung des IP-Headers exakt in das Sichtfenster passt. Außerdem ist überall der Text gut bündig gesetzt: Alle Doppelpunkte stehen untereinander, alle Byte-zu-Bit-Auflösungen stehen genau untereinander. Besser kann eine optische Aufbereitung nicht sein.

Kapitel 1 • Das Werkzeug

51

Abb. 1.18: Der IP-Teil passt genau ins Sichtfenster/optimale Aufteilung

•

Es wird nur das Ergebnis, nicht aber der origniale Bit-Code auf den Monitor gebracht. Beispiel: Ein Unix-Host baut eine Verbindung auf und sendet TCPSYN (= Synchronize); das SYN-Flag ist ein einzelnes Bit innerhalb der TCPFlags. Manche Analyzer sagen zwar korrekt: »TCP-SYN«, zeigen aber nicht, woher sie diese Information haben. Man ist blind dem Analyzer ausgeliefert und man lernt bei dieser erzwungenen Blindheit selber nichts hinzu – aber nur das eigene Wissen um die tatsächlichen Arbeits- und Wirkungsweisen der Protokolle garantiert am Ende auch das Lösen der schwierigsten Fehler.

•

Es erscheinen sämtliche Protokolle in schwarzer Schrift auf weißem Grund – und nicht, wie bei den besseren Analyzern längst üblich, in jeweils eigener Farbe in Abhängigkeit zur jeweiligen OSI-Schicht.

•

Es ist keine Voreinstellung möglich hinsichtlich des Protokolles bzw. der OSISchicht, die man durchsuchen will. Beim Wechsel von einem Frame zum anderen steht der Cursor bzw. das Sichtfenster immer wieder am jeweiligen FrameBeginn (also im MAC-Header), anstatt sich zu »merken«, welches Protokoll bzw. welchen Protokollparameter der Betrachter in jedem Frame sehen will.

52

Geräteklassen

Hier sprechen wir noch gar nicht von inhaltlichen Möglichkeiten wie Offline-Filtering und Namenserkennung; wir sprechen »nur« über die Darstellung der Frames und ihrer Protokolle. An diesen scheinbar simplen Ausstattungsmerkmalen aber scheitert bei den meisten Analyzern schon der schnelle und erfolgreiche Einsatz. Die meisten Analyzer setzen voraus, dass man sich mit Protokollen rein akademisch beschäftigt – jedenfalls nicht unter Zeit- und Erfolgsdruck.

1.2.11 Zwischenfazit Zu den wenigen LAN-Analysatoren, die den Maßstäben des Autors bei Capturing, Filtering und Protocol Decoding gerecht werden (bzw. wurden) und dabei noch ein vertretbares Preis-Leistungs-Verhältnis bieten, gehör(t)en folgende Produkte: Zunächst zwei alte Geräte, die nicht mehr erhältlich sind: LANalyzer (erst Excelan, dann Novell, dann NCC) sowie K1100 (Siemens) – beide wurden vom Markt genommen. (Das ist im Fall von K1100 doppelt bedauerlich, weil die Maschine einerseits verblüffende Fähigkeiten hatte, andererseits der Autor dieses Buches für Siemens die komplette Online-Hilfe für die Protokollerklärungen geschrieben hatte.) Von den aktuellen Produkten hält der Autor den LANdecoder32 (Triticom) für das beste. Darauf wird oft entgegnet, der LANdecoder32 sei in seiner Darstellung und Handhabung »zu technisch« (was immer das bedeuten mag); andere ProfiAnalysten schwören beispielsweise auf den Surveyor (Shomiti), einem zweifellos ebenfalls sehr leistungsfähigen Produkt. Der bekannte Sniffer (früher Network General, jetzt NAI/Network Associates Inc.) bietet beim Filtering zu wenig und ist daher bei schwierigen Fehlern nicht hilfreich genug; bei Standardfehlern ist der Sniffer dagegen stark, weil er Anfängern die Arbeit erleichtert. Als Einsteigerprodukt ist ein solches Werkzeug gut; danach wird der Profi nach anderen oder ergänzenden Möglichkeiten suchen. Komplementär zum Sniffer verhält sich der LANdecoder32, der gerade bei extremen Fehlern die Leistung bietet, die zum Teil selbst Analysatoren aus dem Hochpreissegment nicht bieten. Auffällig ist, dass ausgerechnet der alte LANalyzer sowie der alte K1100 nicht mehr erhältlich sind – als hervorragende HardwareAnalyzer waren sie vermutlich zu teuer und am Ende am Markt nicht mehr akzeptiert.

1.3

Geräteklassen Nunmehr sollen die verschiedenen Geräteklassen dargestellt und gegeneinander abgewogen werden. Auch dies soll helfen, eine angemessene Beschaffungsentscheidung zu treffen.

Kapitel 1 • Das Werkzeug

1.3.1

53

Local Analyzer <> Remote Analyzer Local Analyzer lesen den Datenverkehr mit, den der eingebaute LAN-Adapter »sehen« kann. Bedingung für den Local Analyzer ist, dass er entweder an ein Shared Media LAN (Koax-Kabel, Twisted-Pair-Repeater, Ringleitungsverteiler) oder am Mirror Port (auch: Promiscuous Port) eines Switch angeschlossen ist. Im Falle von Full-Duplex-Anbindungen wäre der Anschluss an ein sog. Full-DuplexTap notwendig. Shared Media LANs sind die herkömmlichen LAN-Techniken, bei denen sich mehrere Endgeräte dasselbe Datenkabel teilen: ARCnet (Datapoint), Ethernet (IEEE 802.3 CSMA/CD), Token-Ring (IEEE 802.5), FDDI (ANSI X3T9.5). Das Shared-Media-Prinzip wird durch Switches aufgehoben und gilt daher niemals für VG-AnyLAN (IEEE 802.12 Demand Priority) oder ATM, die reine Switching-Techniken darstellen. Bei EtherSwitches oder TokenSwitches bleibt die Möglichkeit, Shared-Media-Segmente an die Switches zu koppeln; dann kann der Analyzer wahlweise entweder an das Shared-Media-Segment oder an den MirrorPort des Switch geschlossen werden. Zum Mirror-Port: Sind einzelne Endgeräte – insbesondere Server – an Switches geschlossen, kann ihr Datenverkehr nur mitgelesen werden, wenn der Switch die Server-Daten über einen zusätzlichen Switch-Port ausgibt; diesen Switch-Port nennt man weithin Mirror Port oder Promiscuous Port, weil die Daten eines normalen Ports auf den Analyse-Port »gespiegelt« werden. Unter der Bedingung, dass heute praktisch überall Switches stehen, ist äußerst wichtig, dass bei Beschaffung der Switches auf das Vorhandensein des MirrorPorts geachtet wird – ebenso wie auf das Vorhandensein von SNMP/RMONAgenten. Es sei hier korrespondierend zum Mirror Port, der gewissermaßen den promiscuous mode des Switch darstellt, noch einmal auf die eingangs dargestellte Notwendigkeit hingewiesen, dass der Analyzer seinerseits zugleich im promiscuous mode arbeiten muss (siehe oben). Remote Analyzer lesen nicht selber LAN-Frames ein, sondern lassen dies im jeweiligen LAN-Segment von dort eingebauten Analysemodulen tun; diese Analysemodule sind gemäß Internetstandard sog. RMON-Agenten. RMON heißt Remote [Network] Monitoring. RMON ist ein Schwesterstandard von SNMP, dem Simple Network Management Protocol. Während SNMP eine Abfrage- und Befehlssprache zur Geräteverwaltung ist, ist RMON ein ergänzender Zusatz für die Netzwerkstatistik (RMON-I) und Netzwerkanalyse (RMONII). Nur mit RMON-II kann Paket-Analyse bzw. Capturing betrieben werden. SNMP und RMON sind Internetstandards, festgelegt in sog. RFCs (Request For Comment). Sie sind also herstellerunabhängig.

54

Geräteklassen

Remote Analyzer greifen via IP-UDP-SNMP auf den RMON-Agenten des jeweiligen LAN-Segments zu und veranlassen ihn, die gewünschte Statistik zu liefern oder das geforderte Frame Capturing (»Einfangen« von Daten-Paketen) durchzuführen. Der Remote Analyzer muss als SNMP-Management-Console Zugriff (Zugriffsrechte) auf den RMON-Agenten haben; hierzu wird aktiv eine Verbindung zum RMON-Agenten aufgebaut, was die Kenntnis bzw. Eingabe von drei Angaben erfordert: •

IP-Adresse des RMON-Agenten

•

Community String für GET-Befehle

•

Community String für SET-Befehle

Den sog. Community String kann man im weitesten Sinne als Passwort ansehen – das bei SNMPv1 leider unverschlüsselt, also im Klartext über die Leitung geht. Bei SNMPv2 sind die Authentisierungsdaten verschlüsselt; leider jedoch dürfen SNMPv2-Komponenten die USA nur ohne Verschlüsselungstechnik verlassen, was SNMPv2 in Europa weitgehend sinnlos macht. Die RMON-Agenten können als eigene Hardware-Box im jeweiligen LAN-Segment angeschlossen sein, sofern noch mit Shared-Media-LANs gearbeitet wird; sie können sogar als Software auf PCs laufen (allerdings mit Leistungseinbußen); sie können in aktiven Komponenten wie Router und Switches integriert sein. Während Local Analyzer die LAN-Frames in der Regel 1:1 als Byte-Folge einlesen und abspeichern, erfassen bzw. übertragen die RMON-Agenten die Frames in codierter Form (ASN.1), um Speicherplatz zu sparen. Empfängt ein Remote Analyzer die Captured Frames eines RMON-Agenten und speichert er sie lokal ab, so werden die Frames wieder in originaler, binärer Byte-Folge abgespeichert. Inzwischen wurde mit HS-RMON (High Speed RMON) vom Hersteller Chevin (UK) eine durch Kompression deutlich leistungsstärkere RMON-Variante auf den Markt gebracht. Eine vorbeugende und ständige Beobachtung des unternehmensweiten Datennetzes macht eine möglichst flächendeckende Ausstattung mit RMON-Agenten unausweichlich. Es kann nicht sein, dass für einen kleinen Fehler der Mitarbeiter viele Stunden im Auto sitzen muss, um ins Netz einer fraglichen Niederlassung zu kommen; dies geht via RMON in Sekundenschnelle mit dem Remote Analyzer sehr viel besser. Gleichwohl ist es zwingend notwendig, für die ganz harten Fälle einen guten Local Analyzer parat zu haben, denn einer großen Menge an Messdaten ist kein Remote Analyzer gewachsen: Allein die Zeit, die ein RMON-Agent benötigt, um seine Daten-Puffer zu leeren, indem die Messdaten per IP-UDP-SNMP an die RMON-Console verschickt werden, dauert so lange, dass die Pause bis zur erneuten Datenaufnahme viel zu lang und damit der Datenverlust viel zu groß wird.

Kapitel 1 • Das Werkzeug

55

In der Praxis sieht es oft so aus, dass zunächst einmal ein einzelner Local Analyzer angeschafft wird, um überhaupt eine messtechnische Grundversorgung zu haben; dann wird nach und nach der Ausbau mit RMON-Technik und Remote Analyzer vorgenommen. Dies dauert oft länger, als dies wünschenswert ist, da RMON-Agenten immer noch teuer sind, zumal dann, wenn sie als externe Hardware-Probe benötigt werden. Kaufmännisch bedenklich ist es, wenn zunächst ein Local Analyzer beschafft wird, der sich später nicht zum Remote Analyzer aufrüsten lässt. Zu den Analyzern, die sowohl lokal wie auch per Fernzugriff messen können, gehören (ohne Gewähr der Vollständigkeit): LANdecoder (Triticom), Observer (Network Instruments), Sniffer/SnifferPro (NAI).

1.3.2

Hardware-Analyzer <> Software-Analyzer Remote Analyzer sind immer Software-Analyzer, während die korrespondierenden RMON-Agenten für gewöhnlich (aber nicht notwendig) Hardware-Module sind. Local Analyzer können je nach Bauart Hardware-Analyzer oder Software-Analyzer sein; über sie soll hier gesprochen werden. Software-Analyzer arbeiten über handelsübliche LAN-Adapter. Sie liegen preislich im Bereich von wenigen Hundert Mark bis zu mehreren Zehntausend Mark. Zu den ältesten und ersten Produkten der Familie der Software-Analyzer gehören: Sniffer (Network General, jetzt Network Associates, Inc = NAI), LANalyzer for Windows (Novell), LANdecoder32 (Triticom) und LANwatch (FTP Software). Die Verarbeitung = Auswertung der Messdaten findet beim Software-Analyzer im PC-Prozessor statt. Das bedeutet, dass der LAN-Frame vom LAN-Adapter in den Hauptspeicher des PCs geschoben und erst dort interpretiert wird. Hardware-Analyzer arbeiten eben nicht über handelsübliche LAN-Adapter, sondern über Spezialadapter, die über zusätzliche ASICs und Prozessoren verfügen, in denen die eigentliche Verarbeitung = Auswertung der Messdaten stattfindet. Zu den ältesten und bekanntesten Hardware-Analyzern gehören: DA-30 (Wandel+Goltermann), LANalyzer (Excelan; dann Novell; dann NCC; Novell entwikkelte hieraus den o.g. LANalyzer for Windows), K1100 (Siemens), Internet Advisor (Hewlett Packard). In neuerer Zeit sind hinzu gekommen: Domino (Wandel+Goltermann, als Nachfolger zum DA-30) und Surveyor (Shomiti) sowie Produkte von RADcom, GN Nettest und anderen Herstellern. Software-Analyzer sind in der Regel Offline-Analyzer; Hardware-Analyzer sind in der Regel zugleich Online-Analyzer bzw. Echtzeit-Analyzer (siehe unten). So gut wie jeder Hardware-Analyzer ist in der Leistung einem vergleichbaren Software-Analyzer deutlich überlegen, da zusätzliche ASICs und Prozessoren den PC-Prozessor entlasten und die Auswertung weitgehend on-board stattfindet. Da dies noch während der Messung geschieht, findet die Analyse zu großen Teilen in

56

Geräteklassen

Echtzeit statt. Wegen der zusätzlich erforderlichen Hardware sind die sog. Hardware-Analyzer deutlich teurer als Software-Analyzer – zumindest rechtfertigen die Hersteller die höheren Preise mit diesem Argument. Der Hauptvorteil der Hardware-Analyzer liegt im Bereich des Online-Filtering. Da es sich beim Filtern um eines der drei wichtigsten Merkmale eines LAN-Analysators handelt (neben der Hardware-Nähe und der sog. Expertendiagnose, s.o.), haben die teuren Hardware-Analyzer in jedem Falle ihre eigene Berechtigung. Für den gelegentlichen Einsatz sind sie zu teuer; daher empfiehlt sich oft, statt des einen teuren Hardware-Analyzers besser mehrere Software-Analyzer anzuschaffen. Dies erhöht die Verfügbarkeit des Dienstes »Fehlerdiagnose« bzw. »LANAnalye« im Unternehmen erheblich, da mehrere Mitarbeiter das Wissen aufbauen und unabhängig von nur einer Maschine schneller reagieren können. Es muss berücksichtigt werden, dass sich die Software-Analyzer unterteilen in solche, die über die herkömmlichen Adaptertreiber arbeiten (NDIS, ODI), und solche, die ohne solche Treiber unmittelbar auf den Chip-Satz des LAN-Adapters zugreifen (auch genannt: »direct drivers«, die bereits in der Analyse-Software enthalten sind). Diese speziellen Software-Analyzer kommen in ihrer Leistungsfähigkeit nah an die Hardware-Analyzer heran; berücksichtigt man darüber hinaus ihr interessantes Preis-Leistungs-Verhältnis, so sollte ihre Beschaffung ernsthaft geprüft werden. Als Beispiel hierfür kann der LANdecoder32 von Triticom gelten. Als zwingender Grund, über Software-Analyzer nachzudenken, muss ein messtechnisches Erfordernis gesehen werden: Grundsätzlich müssen für die Fähigkeit, beliebige Fehler sicher analysieren zu können, drei Analyzer für eine sog. Drei-Punkt-Messungvorhanden sein: Ist nicht von vornherein klar, wer oder was den Fehler verursacht bzw. wo er sich tatsächlich ereignet, kann es erforderlich sein, (a) einen ersten Analyzer neben dem Client anzuschließen, (b) einen zweiten Analyzer neben dem Server, auf den seitens des Clients zugriffen wird, (c) in das Netzwerk zwischen beiden. Insbesondere bei Paketverfälschungen oder Laufzeitproblemen kann es schnell zwingend notwendig werden, mit einer Drei-Punkt-Messung zu arbeiten. Wer sich von vornherein auf nur einen Analyzer beschränkt, muss davon ausgehen, dass er bestimmten Fehlerklassen gar nicht mehr zu Leibe rücken kann oder dass dieses nur noch mit unvertretbarem Aufwand an Zeit und Arbeitskraft möglich ist – was im Fehlerfalle schlechterdings untragbar ist. Von dieser Überlegung ausgehend, muss gefragt werden, ob nicht in Zeiten knapper Kassen statt nur eines Hardware-Analyzers besser drei Software-Analyzer beschafft werden. Wenn es möglich sein sollte, drei Hardware-Analyzer zu beschaffen, so wäre das zweifellos angenehm – nur: Wem ist das schon möglich?

Kapitel 1 • Das Werkzeug

1.3.3

57

Hand-held Analyzer <> PC-Analyzer Die meisten LAN-Analysatoren sind PC-gestützt (sei es als Hardware-Analyzer, sei es als Software-Analyzer). Aus der Familie der Kabeltester heraus haben sich jedoch in den letzten Jahren Geräte entwickelt, die längst eine gute und tiefe LAN-Auswertung erlauben; hier seien die Hersteller Fluke und Microtest genannt. Deren Geräte sind sämtlich Hardware-Analyzer; und es sind Hand-held Analyzer, da es sich um kleine, mobile Handgeräte handelt. Da aber nur fest vorgegebene Standardtests bzw. -auswertungen möglich sind, handelt es sich bei diesen LAN-Testern nicht wirklich um Protokoll-Analysatoren im eigentlichen Sinne des Wortes – dazu müssten sie frei programmierbar sein, was sie aber nicht sind. Gleichwohl ist jedem Netzwerkverantwortlichen durchaus zu raten, sich (mindestens) ein solches Gerät anzuschaffen, da es schnell und unkompliziert wichtige Grundaussagen liefert – eben, weil es kaum einer Programmierung bedarf. Eine wichtige Auseinandersetzung mit Kabeltestern als der klassischen Form der Hand-held Analyzer samt einem Vergleich zu vollwertigen LAN-Analysatoren findet sich im nachfolgenden Kapitel.

1.3.4

Echtzeit-Analyzer <> Nicht-Echtzeit-Analyzer Echtzeit-Analyzer verarbeiten die Messdaten (= Captured Frames) sofort nach ihrem Eingang bzw. sogar noch während ihres Eingangs. Sie erlauben zum Teil sogar, noch während des laufenden Capturing ins Protocol Decoding zu gehen, um die bereits eingegangenen Frames schon vor Abschluss der Messung zu durchsuchen. Diese Fähigkeiten setzen Multi-Tasking voraus – was ohne Leistungseinbuße letztlich nur durch Parallel Processing möglich wird, indem die Aufgaben zwischen PC-Prozessor und On-Board-ASICs des LAN-Adapters aufgeteilt werden. Damit sind Echtzeit-Analyzer in aller Regel auf die Familie der Hardware-Analyzer beschränkt. Es gibt Produkte, die als Software-Analyzer einige Echtzeitfunktionen enthalten; so bieten einige Analyzer an, bereits während des laufenden Capturing das Protocol Decoding zu starten – mit dem Ergebnis, dass die Leistung dermaßen schlecht wird, dass der Analyzer im Ernstfall kaum brauchbar ist, weil eine reine PCArchitektur damit hoffnungslos überfordert ist, wenn zugleich auf der Leitung starker Datenverkehr herrscht.

58

Geräteklassen

Hier muss noch ein kleiner Exkurs zum Begriff der »Echtzeitanzeige« eingeführt werden: In der Windows-Welt gilt es als Echtzeitdarstellung, wenn die Zähler auf dem Bildschirm einmal pro Sekunde erneuert werden. Dies ist – pardon!- eine sehr großzügige Auslegung; sie ist für WANs und RMON-Überwachungen vertretbar, aber nicht unbedingt für LANs. DOS-Analyzer können in tatsächlicher Echtzeit die Zähler erneuern. Dies kann von immenser Bedeutung sein beim Erkennen von Fehlern im Physical Layer. Beispiel: Wenn der Zähler bei Ethernet »Collisions« steigt, steigen für gewöhnlich auch die Zähler für »CRC Error«, »Frame Short« und »Alignment Error«. Werden die Zähler aber akkumuliert einmal je Sekunde erneuert, ist nicht erkennbar, ob die Fehler wirklich gemeinsam infolge der selben Kollision auftraten – oder eben doch getrennt und damit wenigstens teilweise auußerhalb von Kollisionen, was Hinweise auf Kabelfehler geben würde. Insbesondere bei schlechter Verkabelung ist darum eine »echte« Echtzeitdarstellung immens hilfreich. Windows-Analyzer helfen da nicht weiter; Kabeltester übrigens oft auch nicht.

1.3.5

Online-Analyzer <> Offline-Analyzer Online-Analyzer erlauben das Protocol Decoding bereits während der laufenden Messung und sind damit Echtzeit-Analyzer. Offline-Analyzer erlauben das Protocol Decoding erst nach Beendigung des Capturing.

1.3.6

Dual-Port Analyzer <> Single-Port Analyzer Software-Analyzer sind in aller Regel Single-Port-Analyzer, weil sie nur Messdaten über ein einziges Interface gleichzeitig einlesen können. Dual-Port-Analyzer können mehrere Datenströme über mehrere Schnittstellen gleichzeitig einlesen und verarbeiten. Sie sind insbesondere interessant, wenn man Kommunikationsgeräte wie z.B. Router untersuchen will, indem man sich sowohl LAN-seitig wie auch WAN-seitig an die Leitung hängt. Sie dienen traditionell wesentlich der Überwachung einer LAN-WAN-Schnittstelle. Dual-Port-Analyzer sind in aller Regel Hardware-Analyzer. Nicht zu verwechseln mit Dual-Port-Analyse ist Multiple-RMON-Analyse, bei der ein Remote Analyzer auf mehrere RMON-Agenten gleichzeitig zugreift.

1.3.7

External Analyzer <> Internal Analyzer Sämtliche oben aufgeführten Geräteklassen gehören zu den externen Analyzern, da es sich immer um eigene Geräte handelt, die zwecks Messung eigens ins Netzwerk gekoppelt werden müssen.

Kapitel 1 • Das Werkzeug

59

Es gibt jedoch auch proprietäre Lösungen, bei denen Analysatoren als Hardware in aktive Netzwerkkomponenten wie Router oder Switches gelegt werden (Internal Analyzer/Built-In Analyzer). Diese Varianten waren in der Zeit vor RMON-II (Protokoll-Analyse im Fernzugriff via SNMP+RMON) von Bedeutung; heute verlieren sich diese Techniken wieder, da der offene Standard RMON-II Vorrang vor proprietären Entwicklungen hat. Eine Ausnahme ist die bereits erwähnte Entwicklung HS-RMON von Chevy.

1.3.8

Active Analyzer <> Passive Analyzer Die meisten Analyzer sind Passive Analyzer, da sie lediglich passiv den Datenverkehr mitlesen und dann auswerten. Active Analyzer jedoch können ins Netzwerk bzw. auf einzelne Komponenten einwirken, um Aussagen über deren Betriebszustand zu erlangen. Eine allgemein bekannte Art der aktiven Messung ist das Aussenden von künstlichen Daten über einen Traffic Generator. Hierbei werden Daten-Frames künstlich ins LAN gesendet, um es auf »Stress« zu testen, also auf fehlerhafte Erscheinungen, wenn das lokale Segment unter Last kommt. Diese Tests sind insbesondere hilfreich, um das Verhalten von Servern, Routern, Switches, Bridges unter Last zu ermitteln oder um z.B. Ethernet-Laufzeit-Überschreitungen zu entdecken. Eine ganze Reihe von Analyzern unterstützt diese Funktion, wobei unterschieden werden muss zwischen solchen Analyzern, die nur »dumme« Testdaten senden, und solchen, die »echte« Frames senden, z.B. aus einer älteren Aufzeichnug. Mit dieser letzten Variante lassen sich Fehler simulieren und wiederholt austesten. (Beispiel: Surveyor/Shomiti.) Weitere Möglichkeiten von aktiven Analyzern reichen vom simplen IP-»Ping« bis zum intelligenten Austesten des Antwortverhaltens von Servern und Clients. Da es Ping und ähnliche Programme (wie z.B. Perform3) inzwischen reichlich als Shareware im Internet gibt, sind sie im Analyzer durchaus verzichtbar; andererseits hat der Wunsch nach »all-in-one« eine eigene Berechtigung. Tatsache ist, dass durchaus nicht alle Analyzer auch aktive Messungen durchführen. Der Bedarf ist erfahrungsgemäß auch nicht immer gegeben. Als Produkte können genannt werden: Observer (Network Instruments), Surveyor (Shomiti), aber auch kleinere Tools wie What’s Up Gold (Ipswitch).

60

1.4

Fazit

Fazit Auch diese Darstellung kann nicht alles klären. Protokollanalyse ist ein extrem schwieriges Handwerk, und die Bewertung des Werkzeuges hängt von einer Vielzahl von Kriterien ab, die wiederum abhängen vom objektiven Bedarf des Anwenders sowie seinen subjektiven Vorkenntnissen und Vorgehensweisen. Der Autor vertritt dezidiert die Auffassung, dass die meisten LAN-Analysatoren unter dem Blickwinkel der Protokollanalyse kein sehr günstiges Preis-Leistungsverhältnis haben und dass nur wenige Produkte im Ernstfall wirklich hilfreich sind (was sich in der langjährigen Praxis des Autors auch mehrfach bewiesen hat). Aber immer gilt: Auch ein zweifelhafter Analyzer ist immer noch besser als gar kein Analyzer! Vor der Beschaffung eines neuen Analyzers aber sollte ein erfahrener Praktiker zu Rate gezogen werden und nicht etwa ein überforderter, unerfahrener Vertriebsbeauftragter im dunklen Zweireiher. Kaufen Sie nicht, ohne das Produkt zuvor in einem 30-Tage-Test ausführlich auf Bedienbarkeit und Programmierbarkeit (Filter!) hin getestet zu haben! Es geht schließlich nicht nur um das Geld dieser einmaligen Anschaffung, sondern auch um das Geld, das Ihrem Unternehmen möglicherweise verloren geht, wenn ein Fehler die Produktion auf Tage lahm legt, weil Sie bzw. Ihr Analyzer nicht helfen können – eben weil es das falsche Gerät ist. Ob ein Analyzer gut ist oder nicht, hängt von den Bedingungen des Umfeldes ab, in dem er eingesetzt wird. Diese Wechselwirkung aber kann nur ausgetestet werden – Hochglanzprospekte vermögen hierüber nichts zu sagen. Vor dem Kauf sollte eine längere Testphase stehen, und als Leitfaden sollten die hier aufgestellten Kriterien gelten; dann kann auch die richtige – heißt: angemessene – Lösung gefunden werden.

Kapitel 2 Hersteller und Produkte 2.1 2.2 2.3

Analyse: Software-Produkte Analyse: Hardware-Produkte Shareware/Freeware

62 67 67

62

Analyse: Software-Produkte

http://www.datalyse.de/ Unter der Adresse www.datalyse.de finden Sie im Internet eine ständig gepflegte Liste des Autors mit allen gängigen Produkten am Markt einschließlich Shareware und Freeware. Die hier kurz vorgestellten Produkte entsprechen dieser Liste. Hier soll Ihnen nur ein kurzer Überblick gegeben werden; über das Internet werden Sie jederzeit mehr erfahren zu den Produkten, als hier sinnvoll dargestellt werden könnte.

2.1

Analyse: Software-Produkte Die Auflistung erfolgt in alphabetischer Reihenfolge der Hersteller.

2.1.1

WildPackets: EtherPeek/TokenPeek http://www.aggroup.de/ Sofware-Analyzer für Ethernet und Token-Ring. EtherPeek und TokenPeek sind nicht so mächtig wie etwa Surveyor oder LANdecoder32, bieten aber schnellen und übersichtlichen Zugriff auf die wichtigsten Netzwerkstatistiken. Datenauswertung ist zwar möglich; die Produkte haben ihre Stärke aber eindeutig im Bereich des Monitoring.

2.1.2

Chevin: CNA Pro/LAN Fox http://www.chevin-analyzer.de/ CNA Pro/LAN Fox ist ein Software-Analyzer mit ausgeprägten Fähigkeiten zur Geräteinventarisierung. Hier ist weniger an spezielle Bit-Fummelei gedacht als an Dokumentation, Erfassung, Wartung. CNA Pro/LAN Fox verfügt über spezielle RMON-Fähigkeiten, da Chevin mit einem besonderen, HS-RMON genannten Verfahren arbeitet. Das Preis-Leistungs-Verhältnis in der flächendeckenden RMON-Überwachung auch der Endgeräte ist ein starkes Plus für das Produkt.

2.1.3

Cinco: NetXRay http://www.nai.com/ NetXRay ging in Sniffer auf. Siehe: NAI/Sniffer.

Kapitel 2 • Hersteller und Produkte

2.1.4

63

GN Nettest: InterWatch/Win Pharaoh http://www.nettestca.gn.com/ Hardware Analyzer für ATM.

2.1.5

Hewlett-Packard: Internet Advisor http://www.hp.com/go/internetadvisor Der Advisor ist ein Hardware-Analyzer, der außerhalb der HP-Kundschaft wenig bekannt geworden ist. Sein Name deutet an, dass er für Internetanalyse gedacht sei; diese Einschränkung aber ist nicht gegeben und nicht gewollt. Wie WWG (s.u.) verkauft HP nur über eigene Vertriebskanäle, weswegen der Autor das Gerät nicht durch die eigene Praxis kennen lernen konnte.

2.1.6

Ipswitch: What’s Up Gold http://www.synapse.de/ipswitch/ Das Produkt steht an der Grenze zwischen Netzwerkanalyse und Netzwerkmanagement; auch steht es zwischen Profiwerkzeug und Tool. Seine Stärke liegt einerseits in der automatischen Erstellung grafischer TopologieKarten mit den im Netz erkannten Komponenten (mit Anzeige des Betriebszustands sowie mit Austesten dieser Geräte); andererseits verfügt es über eine große Zahl aktiver Netzwerktests, wie sie ursprünglich aus der Unix-Welt bekannt wurden wie Ping, TraceRoute, Port Scan, SNMP, DNS LookUp, Finger. Der Name kommt nicht von ungefähr: Die Frage, welches Gerät läuft und welches nicht (»what’s up?«) wird völlig automatisch ohne großes Zutun des Bedieners beantwortet. Automatische Benachrichtigungen an Admins und Operatoren sorgen dafür, dass kein Breakdown unbemerkt bleibt; auch Verminderungen der Betriebsbereitschaft können gemeldet werden. Dies verkürzt die Vorwarnzeiten immens. What’s Up Gold wird im Kapitel »TCP/IP Diagnose-Tools« näher vorgestellt.

2.1.7

LMC: CINeMa http://www.lmc.de/ CINeMa ist eine Software-Lösung, die deutlich mehr auf der Seite des Netzwerkmanagements steht als bei der Netzwerk-Analyse. Dies kann es als Ergänzung zu den Analyzern interessant machen.

64

2.1.8

Analyse: Software-Produkte

NAI/Network Associates, Inc.: Sniffer http://www.nai.com/ Sniffer Sniffer wurde vormals von »Network General« (NG) hergestellt, bevor NG mit McAfee zu NAI fusionierte. In die Enwicklung des aktuellen Sniffer ging der noch von NG aufgekaufte »NetXRay« von Cinco ein. Sniffer war lange Zeit Markführer; es wurde aber zu lange auf DOS gearbeitet; der Umstieg auf Windows fiel schwer. Auch arbeitet Sniffer ohne eigene Hardware. Aus extremen und gründlichen Tests bei Kunden weiß der Autor, dass sich Sniffer eher fürs Monitoring eignet, weil die Paketverlustrate erheblich sein kann. Andererseits sind die Fähigkeiten zum Erkennen gängiger Fehler so interessant, dass der Sniffer als gehobenes Produkt für Einsteiger bzw. Anfänger gesehen werden kann.

2.1.9

NDG Software: EtherBoy/PacketBoy http://www.ndgsoftware.com/ EtherBoy – PacketBoy – WebBoy sind Werkzeuge, die wesentlich dem schnellen Überblick und der Dokumentation dienen. Sie sind weniger für die harte Analyse gedacht (die viel Wissen voraussetzt), sondern für den schnellen Einstieg auch von Anfängern. Das Produkt ist ein Software-Analyzer nur für Ethernet (kein Token-Ring).

2.1.10 Net3Group: NetSense/ProConvert http://www.net3group.com/ NetSense analysiert Trace-Daten fast beliebiger Analysatoren. ProConvert kann zwischen den verschiedenen Trace-Formaten konvertieren. Net3Group stellt nicht selber Analyzer her, sondern bietet Add-On-Produkte, die teilweise erheblichen Mehrwert bieten.

2.1.11 Network Instruments: (Distributed) Observer http://www.observer-analyzer.de/ Unter den mehr für Statistik und Monitoring ausgelegten Produkten steht Observer ganz an der Spitze.

Kapitel 2 • Hersteller und Produkte

65

Er ist hervorragend zur laufenden Beobachtung mit Dauerstatistik geeignet, zumal RMON-Fähigkeiten gegeben sind. Die Online-Darstellungen sind so vielfältig, dass auch nach langer Anwendungszeit immer noch zusätzliche Funktionen gefunden werden können. Eine der Stärken von Observer liegt darin, dass Verkehrsprofile von LANs gespeichert und mit aktuellen Verkehrsszenarios verglichen werden können. Auf diese Weise können nicht nur Trends dokumentiert werden (für die Migration des Netzwerkes wichtig), sondern es kann auch Qualitätssicherung betrieben werden, wenn Verkehrsprofile als Soll-Maßstab hinterlegt werden.

2.1.12 Novell: LANalyzer for Windows/ManageWise http://www.novell.com/ Der erste LANalyzer wurde als Hardware-Analyzer unter DOS ursprünglich von Excelan entwickelt, wurde dann von Novell übernommen und zum WindowsAnalyzer weiterentwickelt. Der DOS-Hardware-Analyzer wurde an NCC weiterveräußert und ist heute nicht mehr am Markt. LANalyzer for Windows (LfW) ist auf die Novell-Umgebung abgestellt und ging u.a. in die ManageWise-Suite ein. Die Decodierung des NetWare-Protokolls NCP ist mit LfW immer noch sehr gut – hier arbeitet eben derselbe Hersteller. Die Zuverlässigkeit in der Paketaufnahme ist begrenzt, da LfW ein SoftwareAnalyzer ist.

2.1.13 Precision Guesswork: LANwatch32 http://www.guesswork.com/ LANwatch (DOS) wurde ursprünglich von FTP Software entwickelt, bevor das Produkt von Guesswork übernommen wurde. Die Entwicklung des Produkts wurde nicht mehr sehr entschieden verfolgt.

2.1.14 RADcom: RC-88 – RC-100 http://www.radcom-inc.com/ Hardware-Analyzer für Ethernet und ATM.

2.1.15 RzK: NetQ&A – NetControl http://www.rzk.com/ Analyse-Module, die auf die Ausgabe von Netzwerkstatistiken im HTML-Format spezialisiert sind. Keine eigentliche Analyse.

66

Analyse: Software-Produkte

2.1.16 Shomiti: Surveyor/Century Tap http://www.shomiti.com/ Der Surveyor kann mit und ohne Hardware-Modul betrieben werden. Als OnlineAnalyzer ist der Surveyor eines der wenigen Profiwerkzeuge. Die Hardware-Unterstützung erlaubt dem Surveyor ausgezeichnete Online-Auswertung, die die überwiegend gängigsten Fehler in Echtzeit erkennt und darstellt. Der Surveyor stellt neben dem LANdecoder32 (Triticom) das zentrale Messgerät für den Autor und seine Firma dar. Der externe Century Tap kann zwischen Switch und Endgerät gesetzt werden, um daran den Analyzer koppeln zu können.

2.1.17 Triticom: LANdecoder32 http://www.synapse.de/deutsch/d_triticom_produkte.htm Software-Analyzer mit Direktzugriff auf die Hardware des LAN-Adapters, der die Messdaten einliest. LANdecoder32 ist extrem zuverlässig in der Datenaufnahme; dafür wurden die Online-Statistiken begrenzt. Das Expertensystem, die extrem gute Darstellung sowie das hervorragende Decoding in der Auswertung der Messdaten machen den LANdecoder32 zum bevorzugten Werkzeug des Autors (neben einigen anderen Produkten). Mit RMON-Analyse bei Zugriff auf unbegrenzt viele RMON-Agenten gleichzeitig eignet sich LANdecoder32 zur Überwachung verteilter Netzwerke und Segmente.

2.1.18 Wavetek Wandel Goltermann: Domino http://www.wg.com/ Domino ist der Windows-Nachfolger des legendären DA-30. Domino verfügt über ein eigenes Hardware-Modul. Da WWG nur über eigene Vertriebswege verkauft, gehört der Domino zu den wenigen Analyzern, die der Autor nicht aus eigener Praxis kennt. Soweit dies bei Kunden sichtbar wurde, verfügt der Domino über ein gutes Handling; insbesondere Einsteiger werden sich gut zurechtfinden.

Kapitel 2 • Hersteller und Produkte

2.2

67

Analyse: Hardware-Produkte Die hier aufgeführten Produkte sind als Hand-Helds inzwischen weit über das Maß eines Kabeltesters hinausgewachsen. Sie sind weiterhin wegen ihrer Tragbarkeit gut für den praktischen Einsatz geeignet; aus der Sicht des Autors aber ist ein Protokollanalysator derselben Preisklasse (oder sogar darunter) einem solchen Gerät immer vorzuziehen. Die Auflistung erfolgt in alphabetischer Reihenfolge der Hersteller.

2.2.1

Fluke: OneTouch – LAN Meter http://www.fluke.de/ LAN Hardware Tester/Kabel-Tester. Automatische Erkennung von Fehlern, aktiven Komponenten, Auffälligkeiten.

2.2.2

Microtest: Omni/Penta/Micro Scanner http://www.microtest.de/ LAN Hardware Tester/Kabel-Tester. Automatische Erkennung von Fehlern, aktiven Komponenten, Auffälligkeiten.

2.3

Shareware/Freeware http://www.datalyse.de Liste des Autors zu Analyseprodukten. Die Auflistung erfolgt in alphabetischer Reihenfolge der Produkte.

2.3.1

4Net http://www.cartoonlogic.com/4net/ Einfaches Tool zur Orientierung im Netzwerk.

2.3.2

Any Speed http://www.pysoft.com/ Dieses Programm arbeitet auf der Basis des Ping-Mechanismus und testet die Zuverlässigkeit, den Datendurchsatz sowie die Antwortzeit auf ausgewählten Netzwerk-Verbindungen aus. Insbesondere für WAN-Netze ist AnySpeed ein hervorragendes Tool.

68

Shareware/Freeware

Any Speed wird im Kapitel »TCP/IP Diagnose-Tools« näher vorgestellt.

2.3.3

Big Brother http://maclawran.ca/sean/bb-dnld/index.html Überprüft Hosts und TCP-Dienste in TCP/IP-Netzen. Das Programm testet, ob ein Rechner überhaupt übers Netz erreichbar ist, ob die http-, ftp- und POP3-Server arbeiten, wie stark CPU und Platte ausgelastet sind und ob bestimmte systemkritische Prozesse laufen. Die Ergebnisse werden grafisch aufbereitet und als Webpage bereitgestellt (Freeware).

2.3.4

Free Wizard http://www.freewizard.com/ Dies ist eine Internetseite, die weitere Shareware-Tools führt.

2.3.5

IDyle GimmIP http://www.idyle.com/gimmip/ GimmIP (Wortspiel: »give me IP«) überwacht die IP-Verbindungen, die man ins Internet aufbaut, und zeigt den Status an. Probleme wie Fehler in der DNSAdressauflösung werden erkannt.

2.3.6

Internet Anywhere Toolkit http://www.zdnet.de/download/library/00I80-wf.htm Durchblick im Internet: Die für IP bekannten Tools werden hier eingesetzt: Ping, TraceRoute, WhoIs und weiteres.

2.3.7

Internet Maniac http://www.zdnet.de/download/library/00PJV-wf.htm (Ohne Beschreibung.)

2.3.8

IP Network Browser http://SolarWinds.net/ Analyse von TCP/IP-Netzwerken (SNMP-basierend). Die Software durchsucht das ganze Netz nach TCP/IP Adressen und zeigt ihre IPAdresse sowie den DNS-Namen an.

Kapitel 2 • Hersteller und Produkte

69

Bei Rechnern und Netzwerkgeräten wie Switches oder Hubs, die SNMP unterstützen, liefert der Network Browser alle Informationen, die über dieses Protokoll zur Verfügung stehen. (Shareware)

2.3.9

IP Sentry http://www.ipsentry.com Überwachung von Hosts und TCP-Diensten auf TCP/IP-Netzwerken (Shareware).

2.3.10 IP Subnet Calculator http://www.net3group.com/ Dieses kleine Programm behebt das lästige Problem, die Subnetz-Masken in IPAdressen zu berechnen. In der Liste der Analyseprodukte findet sich von Net3Group das Produkt NetSense (Freeware).

2.3.11 NeoTrace http://www.neoworx.com/ NetTrace arbeitet mit dem TraceRoute-Mechanismus und baut automatisch Landkarten mit Hintergrund-Maps auf (15-100 US$).

2.3.12 NetCat http://www.l0pht.com/~weld/netcat/ TCP/IP-Werkzeug zur Nutzung einzelner TCP-Dienste, einschließlich Port-Scanner (Freeware).

2.3.13 NetoScope http://www.basta.com/ NetoScope überwacht Internet-Server, etwa FTP-Server, WWW-Server oder Mail-Server. Die Auslastung des fernen Servers wird abgeschätzt; bei Fehlern oder Ausfällen erfolgt Benachtigung per Mail oder Pager.

2.3.14 Netscan Tools http://www.nwpsw.com/ http://www.netscantools.com/ Finger, TraceRoute, Timesync, Überprüfung der TCP-Dienste mit Port-Nummer mit grafischer Oberfläche (Shareware).

70

Shareware/Freeware

2.3.15 Ping Plotter http://www.nessoft.com/pingplotter/ Grafisches Traceroute mit Performance-Graph der einzelnen Hops (Freeware).

2.3.16 PortFlash http://www.webroot.com/ Port-Scanner für TCP-Dienste auf TCP/IP-Netzen (Shareware).

2.3.17 Recon-1 lite http://www.peakcom.com/recon-1/index.htm/ Netzwerk-Überwachung und -Analyse für TCP/IP mit Browser-Interface zur Abfrage der gesammelten Informationen. Das Programm überprüft in regelmäßigen Abständen alle Hosts, die es im Netz findet. Dabei stellt es nicht nur fest, welche TCP-Dienste aktiv sind, sondern auch die MAC-Adresse der Netzwerkkarte und die gesendeten und empfangenen Datenpakete. Diese unterscheidet es nach diversen Kriterien und kann auch fehlerhafte Pakete erkennen (Freeware – Profiversion ist Shareware).

2.3.18 Remote Logout http://www.hostus.com/ Client/Server-Programm zum Abmelden von Benutzern, Herunterfahren und Neustarten von Maschinen mit Windows NT (Shareware).

2.3.19 Remotely Possible http://www.avalan.com/ Dieses Programm bietet Fernzugriff auf Netzwerkrechner; dies kann bei der Diagnose von Maschinenproblemem helfen.

2.3.20 Servers Alive? http://www.woodstone.nu/salive/ Überwachung von Servern in Windows-Netzwerken. Das Programm überprüft alle angegebenen Rechner in einstellbaren Abständen, ob sie noch aktiv sind. Dies kann über einfaches Ping geschehen, aber auch durch testen bestimmer TCP-Ports.

Kapitel 2 • Hersteller und Produkte

71

Bei NT-Rechnern unterstützt das Programm sogar bestimmte NT-Dienste oder untersucht den verbleibenden Festplattenplatz (Shareware).

2.3.21 Sniff It http://reptile.rug.ac.be/~coder/sniffit/sniffit.html Linux Packet-Sniffer (Protokoll Analyser) zur Analyse von Datenpaketen auf TCP/IP-Netzen (Freeware).

2.3.22 Subnet Wiz http://tucows.cableinet.net/ TCP/IP-Subnet-Ermittlung mit grafischer Oberfläche. Subnet Wiz erwartet die Angabe einer IP-Adresse. Anschließend lassen sich entweder die gewünschte Anzahl an Host, an Subnets, die Subnetzmaske oder die Netzwerk-Bits auswählen. Daraufhin überprüft das Programm, ob die angegebene IP-Adresse gültig ist und berechnet Masken und IP- sowie Broadcast-Adressen für alle erlaubten Subnetze (Shareware).

2.3.23 Visual Route http://www.visualroute.com/ Grafisches TraceRoute mit Performance-Analyse und -Graph. Das Programm erklärt nach Eingabe einer IP-Adresse oder eines Host-Namens in deutlicher Sprache, an welcher Stelle es im Netz klemmt. Antwortzeiten werden übersichtlich in einer Tabelle eingetragen und grafisch dargestellt. Der Clou: Auf einer Weltkarte zeichnet das Programm den Weg der Päckchen zum Zielrechner ein (Shareware).

Kapitel 3 Grundlagen der Methodik 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11

Eingrenzung von Maschine, Schicht, Ort Die klassischen Netzwerkfehler Erste Schritte Die Windows-Registry Deutung der Ereignisse und Messdaten Statistik in Intervallen: Snapshots Trace-Bibliotheken – ein wertvolles Gut! Online-Publishing im Ernstfall Psychologie und Nervenstärke! Vorbeugen ist besser als Bohren Permanente Qualitätssicherung

74 75 76 87 91 98 100 101 102 103 104

74

Eingrenzung von Maschine, Schicht, Ort

Wie findet man die sprichwörtliche »Nadel im Heuhaufen«? Der eine mag es mit Magneten versuchen (scheitert aber an Alu-Nadeln), der andere mag es mit Gebläse-und-Schwerkraft versuchen ... jeder mag seine eigene Idee haben, und jede Idee wird ihre eigene Berechtigung haben. LAN-Analyse ist in gleicher Weise immer wieder auf neue Ideen angewiesen (weil sich immer wieder neue, nicht gekannte Herausforderungen einstellen): Und doch muss eine Methodik eingeübt sein, die zuverlässig auch dann funktioniert, wenn sich ein gänzlich neues, unbekanntes Fehlerszenario ereignet. Die folgenden Ausführungen versuchen, ein solches allgemein gültiges Handlungsmuster zu entwickeln:

3.1

Eingrenzung von Maschine, Schicht, Ort Als erstes werden folgende Eingrenzungen vorgenommen: •

Welche Protokolle oder Netzwerkfunktionen stehen in Verdacht, Ursache des Fehlers zu sein?

•

Welche Maschinen sind betroffen bzw. stehen in Verdacht?

Es wird das beteiligte Protokoll eingegrenzt bzw. die beteiligte Netzwerkschicht (OSI-Layer). Das bedeutet etwas allgemeiner gesagt: Die beteiligte Funktion wird eingegrenzt. Zur Wahl stehen für gewöhnlich vier Kernpunkte: •

Fehler im lokalen Übertragungssystem (LAN) = physikalische Fehler

•

Fehler im Internetworking (Vermittlung) = Routing-Fehler

•

Fehler in der Data Flow Control (oft die Transportschicht, aber nicht nur)

•

Fehler in der Namens- und Adressauflösung (ARP, DNS, WINS etc.)

Wenn sich in diesen vier Bereichen kein Fehler nachweisen lässt, liegt die Ursache meistens in einem der folgenden Bereiche: •

Fehler in der Applikation

•

Fehler im Betriebssystem (bei Client oder Server)

Ob dann noch von einem »Netzwerkfehler« gesprochen werden kann, mag fraglich erscheinen. Allgemein gilt folgende Faustregel: Je »tiefer« der Fehler liegt im System der Netzwerkschichten (also in OSI-Layer 1 oder 2), umso einfacher ist der Fehler zu finden – und umgekehrt.

Kapitel 3 • Grundlagen der Methodik

75

Abb. 3.1: Das umgekehrte Verhältnis von Aufwand und Netzwerkschicht

Abbildung 3.1 soll das verdeutlichen: Je niedriger die Netzwerkschicht (Physical, Data-Link, Network), umso geringer sind Zeit und Aufwand zu veranschlagen zum Auffinden des Fehlers. Je höher die Netzwerkschicht (Transport, Session, Presentation, Application), umso größer muss der Aufwand veranschlagt werden, diese Fehler zu erkennen und abzustellen. Hier ist zudem noch eine historische Komponente gegeben: Bis Anfang der 90er Jahre galt, dass die meisten Fehler auf Layer 1,2 stattfanden – weil mit den überaus fehleranfälligen Koax-Kabeln gearbeitet wurde – , heute ist dies nicht mehr so. Allgemein ist der Physical Layer mit einer fachgerecht durchgeführten TwistedPair-Verkabelung kaum noch störanfällig; und wenn mal ein Fehler auftritt, so betrifft er in aller Regel nur ein Anschlusskabel und daher nur ein Endgerät. Bei einem solchen Szenario ist es oft schon unnötig, den Analyzer zu starten, da ein einfacher Kabeltausch die Vermutung bestätigt und den Fehler beseitigt. Eher schon können sich Fehler in Bridges und Switches ereignen, also ggf. kombiniert auf den beiden OSI-Schichten 1 (Physical Layer) und 2 (Data Link Layer). Meistens ereignen sich die Netzwerkfehler in Twisted-Pair-LANs aber ab OSISchicht 3 (Network Layer) oder höher. Gleichwohl: Die Vorgehensweise des Messtechnikers muss darauf abgestimmt sein, dass sie jeden Fehler erfasst. Wichtige Abschnitte hierzu sind 3.3.4 bis 3.3.7.

3.2

Die klassischen Netzwerkfehler Die häufigsten Fehler in Datennetzen lassen sich wie folgt zusammenfassen: Grundsätzlich kann man folgende Fehlerquellen abstrakt in Klassen fassen:

76

Erste Schritte

OSI Layer

Fehlerklasse, Protokolle (OSI Layer)

A

1,2

Broadcast-Stürme, bedingt durch Fehler in der Netzwerk-Hardware (1,2) oder in den Konfigurationen (2-7).

B

2,3,5,7

Adress- und Namensauflösung (Resolution) bzw. Abfragen von Namen und Adressen (LookUps): ARP-RARP (2,3), BOOTP (2,3), DHCP (2,3,5,7), WINS (3,5), DNS (3,7)

C

2,3

Fehler im Routing bzw. in der Netzwerkvermittlung Token Ring (2), IP (3), IPX (3)

D

2,4,7

Fehler in der Datenfluss-Steuerung (Data Flow Control) LLC (2), TCP (4), NCP (7), SMB (7)

Tab. 3.1: Die klassischen Fehlerquellen in LANs und WANs

Entsprechend muss auch die Vorgehensweise sein: Während grundsätzlich innerhalb des OSI-Modells die Schichten von unten nach oben auf Fehler und Auffälligkeiten hin untersucht werden, muss gleichzeitig in den hier genannten Kategorien vorgegangen werden. Daraus ergibt sich in der Praxis ein mehrdimensionales Vorgehen, da man bei der Durchsicht von Messdaten mindestens zwei parallele Schemata abarbeitet: •

Die Vorgehensweise orientiert sich an den bekannten Schichten gemäß dem OSI-Modell (von unten nach oben).

•

Die Vorgehensweise orientiert sich an Funktionen der Datenkommunikation bzw. Fehlerklassen (siehe Tabelle).

Während die Funktion »Routing« klar auf OSI-Schicht 3 liegt (wenn man mal das Token-Ring Source-Routing außer Acht lässt), ist die Funktion Datenflusskontrolle (Data Flow Control) bald auf jeder Schicht anzutreffen (unter Einschluss der WAN-Techniken ISDN, ATM und X.25 finden wir Data Flow Control tatsächlich auf mindestens fünf der sieben Schichten).

3.3

Erste Schritte Die ersten Schritte hängen davon ab, •

ob ein hauseigener Techniker am LAN-Analyzer arbeitet, oder ob ein externer Dritter (Dienstleister) an die Leitung geht;

•

ob die Ursache des Fehlers von vornherein einen bestimmbaren Ort hat;

•

ob der Fehler reproduzierbar ist (also beliebig erregt werden kann).

Kapitel 3 • Grundlagen der Methodik

3.3.1

77

Interner oder externer Techniker? Der interne Techniker »kennt« seine Server, Router, Switches ... das nehmen wir wenigstens einmal an und tun so, als sei das leidige Dokumentationsproblem gelöst oder nicht von Belang. Allerdings zeigt die Erfahrung, dass selbst interne Kräfte nicht über ausreichende Dokumentation verfügen, auch nicht über hinreichende Kenntnisse, mit welchen »Lebenszeichen« sich die verschiedenen Komponenten bemerkbar machen (AMP/SMP, BPDU, RIP, OSPF etc.). Der externe Techniker hat dagegen erst gar keine Dokumentation; und bis sie ihm denn vorgelegt wird – sofern überhaupt vorhanden – , kann er sich längst die nötige Information weitgehend selbst besorgen. Es sei verwiesen auf das Kapitel 6, »Die Notfallmessungen«, in dem das Zusammenspiel zwischen Auftraggeber und externem Dienstleister eigens dargestellt wird.

3.3.2

Dokumentation – ja oder nein? Grundsätzlich stellt sich zum Thema »Dokumentation« eine für die messtechnische Methodik wichtige Frage: Gesetzt den Fall, es sei eine Dokumentation gegeben: Soll man sie benutzen, sie zu Rate ziehen, sie zum Ausgangspunkt der Messungen machen? Die Antwort lautet klar und entschieden: »jein«. •

Für die Verwendung von Dokumentationen spricht: Es kann wichtige Zeit gespart werden, die man sonst darauf verwenden müsste, sich die benötigte Information selber zu beschaffen.

•

Gegen die Verwendung von Dokumentationen spricht: Es kann wichtige Zeit verloren gehen, wenn man sich auf Angaben verlässt, die falsch sind – und zwar so, dass man es nicht sofort bemerkt. Hier muss berücksichtigt werden, dass viele Fehler darin begründet liegen, dass die fürs Tagesgeschäft zuständigen Admins, Operatoren und Techniker selber aufgrund falscher Annahmen bzw. fehlender oder unzutreffender Dokumentationen gehandelt haben – und das oft über sehr, sehr lange Zeiträume. Diese Menschen können gar nicht anders, als einem – zumal externen – Messtechniker ständig das zu erzählen, was sie für gegeben halten. Genau das aber kann völlig falsch und letztlich die Ursache des Fehlers sein. Aus diesem Grunde ist es gut und hilfreich, sich die Aussagen anzuhören und die Dokumentation anzusehen – aber jeder Messtechniker sollte sich davor hüten, dem blind zu vertrauen.

Aus den vorgenannten Gründen hat der Autor ein festes Handlungsschema, wenn er im Notfall zu Kunden gerufen wird: Bevor er sich irgendetwas vom Kunden vorlegen lässt, und bevor der Kunde beginnt, langatmig zu erzählen, hängt er sei-

78

Erste Schritte

nen Analyzer an die Leitung und bittet um ein bis zwei Stunden Ruhe und Einsamkeit. Dann ist eine objektive Basis für alles Weitere gegeben. Das aber setzt natürlich voraus, dass der Messtechniker in jedem Falle genau weiß, was er tut – und dass er auch die Verantwortung tragen kann.

3.3.3

Der erste, schnelle Überblick Angesichts fehlender oder unzureichender Dokumentation sehen die ersten Schritte wie folgt aus: •

Erster Schritt: Broadcasts & Multicasts Filter auf Broadcasts und Multicasts setzen; dann den Analyzer 60+1 Sekunden laufen lassen (oder länger). Denn so gut wie alle aktiven Komponenten geben einmal je 60 Sekunden ein Zeichen von sich: Dies sind Router Exchange Protocols (RIP, NWRIP, OSPF, IGRP, E-IGRP, NLSP etc.), Service Advertising Protocols (NWSAP etc.), Bridge PDUs (Spanning Tree) und ähnliche Meldungen. Ohne diese Orientierung ist eine Analyse gewissermaßen blind.

•

Zweiter Schritt: Adressen & Namen Filter auf alle Vorgänge setzen, die mit Namens- und Adressauflösung bzw. Adresszuweisungen zu tun haben: ARP, R/ARP, DNS, WINS, BOOTP, DHCP, ICMP, NetBIOS, AMP/SMP etc. Die Ergebnisse dieses Schrittes vertiefen nicht nur die mit dem ersten Schritt gewonnen Erkenntnisse (zumal Protokolle wie RIP und NWSAP auch zudem erneut im zweiten Schritt betrachtungswürdig sein können); es können auch die ersten Fehler gefunden werden. Im Falle von TCP/IP müssen die ARP-Tabellen der verschiedenen IP-Subnets vorliegen, um jeder MAC-Adresse die entsprechende IP-Adresse zuordnen zu können.

Welche Produkte sollte man für diese Arbeiten einsetzen? Es gibt Werkzeuge, welche die aktiven Komponenten mit ihren Adressen und Namen automatisch sichtbar machen: Router, Bridges/Switches, RMON- und SNMP-Agenten, Server usw. Als ein Beispiel seien der »Observer« (Network Instruments) genannt oder »What’sUp Gold« (IpSwitch). Diese Werkzeuge können z.T. auch per »Auto-Topology«/»Auto-Map« die gefundenen Komponenten auf dem Bildschirm gemäß der Subnet-Struktur (IP, IPX) anordnen. Jedoch: So schön diese Werkzeuge auch sind, so muss man doch sehen: Sie nutzen nur in den ersten Minuten; danach weiß man, was man wissen muss, und danach wird’s langweilig.

Kapitel 3 • Grundlagen der Methodik

79

Das ist übrigens oft der ernüchternde Effekt bei Käufern: Bei der Vorführung waren sie noch durch den »Aha«-Effekt begeistert, und nach dem Kauf bzw. wenige Wochen später steht die Frage im Raum, was man denn nun damit eigentlich noch anfangen solle. Für einen ersten Überblick aber sind diese Werkzeuge unverzichtbar (zumindest für den Laien oder weniger erfahrenen Messtechniker). Danach ist der Messrechner mit einem qualifizierten Analyzer besser eingesetzt als mit einem solchen – zugegeben intelligenten – LAN-Monitor. Ein gut ausgerüsteter Messtechniker muss also verschiedenen Analyseprogramme auf seinem Rechner haben: Eine Vorgehensweise Schritt für Schritt verlangt eben auch für jeden Schritt das angemessene Werkzeug. Der Autor vollzieht sämtliche dieser Schritte regelmäßig mit dem von ihm eingesetzten LANdecoder32 (Triticom) sowie den Add-Ons NetSense (Net3Group) LANreport (Synapse), welche die Messdaten auswerten und die gewünschten Ergebnisse druckfertig ausgeben: Server, Router, ARP-Tabellen und so weiter. Hierauf wird an anderer Stelle noch weiter einzugehen sein.

3.3.4

Eingrenzung des Ortes Manchmal ist von vornherein klar, dass der Fehler von einem Server oder Router verursacht wird. Diese Fälle sind jedoch selten; meistens zeigt sich, dass schwere Fehler mehr als nur eine Ursache haben. In den meisten Fällen, in denen der Verfasser gerufen wird, liegen mehrere Ursachen mit mehreren Wirkungen und Wechselwirkungen gleichzeitig vor – was die Arbeit nicht eben leichter macht. Vor eiligen und leichtfertigen Schlüssen kann nur gewarnt werden! Es muss berücksichtigt werden, dass die Tatsache, dass eine Komponente erkennbar falsch arbeitet, noch lange nichts über die Kernfrage aussagt, ob diese Komponente denn nun •

Täter ist,

•

Opfer ist,

•

oder beides zugleich.

Das heißt, es stellt sich immer die Frage, ob eine falsch arbeitende Komponente selber den Fehler aktiv verursacht (also Täter ist/endogene Ursache), oder ob sie passiv auf externe Ereignisse auf der Leitung reagiert (also Opfer ist/exogene Ursache). Es ist zu berücksichtigen, dass die Hardware-/Software-Entwickler niemals alle denkbaren Fehler auf der Leitung – also etwa falsch bediente Protokolle – vorweg nehmen können, um ihre eigene Komponente zu einer fehlertoleranten Reaktion zu bringen. Dies ist nur sehr begrenzt möglich.

80

Erste Schritte

Angenommen, ein Arbeitsrechner sendet falsch formatierte IP-Pakete, und ein Router »versteht« das nicht und »beschließt« daraufhin, sämtliche IP-Pakete in falsche Subnetze zu vermitteln – ist der Router dann Täter oder Opfer? Er wäre offensichtlich beides zugleich. Und wenn dann aufgrund dieses Ereignisses der Nettodatendurchsatz seitens der Anwender massiv vermindert und die Antwortzeiten massiv erhöht werden, heißt es: »Das Netzwerk ist langsam«, und zugleich: »Ja, aber – wir haben doch nur 10% Netzlast!?« Spätestens hier wird sichtbar, dass einfache Aussagen bzw. einfache Annahmen schnell in die Irre führen können. Wenn man dann noch hinzunimmt, dass bei einem solchen Szenario die Server wiederum auf die Idee kommen könnten, laufend den Router zu wechseln, könnte ein vorschnell urteilender Analyst sogar noch die Behauptung aufstellen, die Server seien defekt – mit der Folge, dass noch Zeit und Geld in den Umbau bzw. in die vermeintlich fällige Aufrüstung der Server gesteckt wird. Dies sei abwegig? Mitnichten: Das ist die tägliche Praxis »da draußen«. Die Eingrenzung des Ortes wird also schnell schwieriger, als es auf den ersten Blick erscheint.

3.3.5

Eingrenzung der Netzwerkschicht Weiterhin muss Ihnen immer bewusst sein, dass die modulare Trennung der OSILayer reine Theorie ist. Tatsächlich kann ein Protokollfehler auf Schicht A schnell Auswirkungen auf Schicht B haben. Ein Beispiel: Ein Routing-Fehler auf der Vermittlungsschicht (OSI Layer 3) kann sich in ReTransmissions der Transportschicht (OSI Layer 4) bemerkbar machen. Umgekehrt können sich die auf Schicht 4 via TCP ausgehandelten Paketgrößen auf das Routing der Schicht 3 auswirken. Es kann sogar sein, dass ein Fehler auf der Anwendungsschicht (OSI Layer 7) dazu führt, dass es Fehler im Routing gibt (OSI Layer 3), was sich dann wiederum letztlich in Ereignissen (nicht Fehlern!) der Transportschicht (OSI Layer 4) in Form von ReTransmissions niederschlagen kann; und wenn dann noch durch puren Zufall gelegentlich physikalische Fehler auftreten, wird die Situation vollends unübersichtlich. Ursache und Wirkung sind zwar letztlich immer klar gegeben – aber das Verhältnis zwischen beiden ist eben nicht immer auf den ersten Blick klar erkennbar. Dies führt dazu, dass man bei der Eingrenzung des Fehlers bzw. seines logischen Ortes im Sinne des OSI-Layers alle Protokollschichten zugleich im Blick haben muss sowie alle nur denkbaren Wechselbeziehungen zwischen ihnen.

Kapitel 3 • Grundlagen der Methodik

81

Insbesondere im Kapitel zur TCP/IP-Analyse wird auf solche Wechselwirkungen hingewiesen.

3.3.6

Verkehrstabellen Für das schnelle Eingrenzen des Ortes, teilweise auch der Netzwerkschicht oder des Protokolls, sind sog. Verkehrstabellen immens wichtig. Einige besondere Aspekte hierzu werden im Kapitel »Der Physical Layer« beschrieben. Hier sei allgemein Folgendes aufgeführt: Schnelles Erkennen eines Dialogzustandes Verkehrstabellen erlauben in den überwiegend meisten Fällen, schnell und zuverlässig den Status eines Client-Server-Dialoges zu ermitteln.

Abb. 3.2: Verkehrstabelle mit dem MAC-Paaren

Sowohl auf Layer 2 (MAC) wie auch auf Layer 3 (IP, IPX) werden bestimmte Fehlerklassen schnell isoliert und erkannt, wenn die folgenden Fragen durchgegangen und beantwortet werden. Die Verkehrstabellen ermöglichen schnell und sicher die Anwendung eines effizienten Ausscheidungssystems:

82

Erste Schritte

Abb. 3.3: Verkehrstabelle mit den IP-Paaren

3.3.7

Fragen und Antworten/Ausscheidungssystem Eine wichtige Technik ist das schrittweise Isolieren des Fehlers, indem möglichst viele andere Varianten ausgeschlossen bzw. ausgeschieden werden. Es ist wesentlich einfacher, in einem vorab eingegrenzten Bereich mit der Suche nach der berühmten Stecknadel zu beginnen, als den ganzen Heuhaufen nach ihr durchsuchen zu müssen! Das folgende Frage-und-Antwort-Schema hat sich über Jahre bewährt: Messpunkt bzw. Ort der Messung Wo war der Messpunkt, an dem die Statistik erzeugt wurde? •

Hat die zur Statistik führende Messung (per Analyzer oder per SNMP+RMON) stattgefunden – im Client-Segment, also etwa am Arbeitsgruppenverteiler, – im Server-Segment, in der Server-Farm bzw. am RZ-Switch, – im Backbone zwischen Client und Server?

Kapitel 3 • Grundlagen der Methodik

•

83

Wenn die der Statistik zugrunde liegende Messung ... – im Client-Segment stattfand und mit Switches gearbeitet wird, sind angezeigte physikalische Fehler auch dort im Client-Segment zu suchen; – im Client-Segment stattfand und mit Repeatern (Ethernet) gearbeitet wird, sind die angezeigten physikalischen Fehler nur noch eingrenzbar, wenn bei Kollisionen zwischen Local Collision, Remote Collision und Late Collision unterschieden werden kann, beispielsweise durch An- oder Abwesenheit von Stopf-Bits in den Frames (siehe Kapitel 12, »Ethernet«); handelt es sich nicht um Kollisionen, ist der Fehler nicht ohne weitere Maßnahmen eingrenzbar; – im Server-Segment stattfand und mit Switches gearbeitet wird, und sofern ein Medium-Tap bzw. Medium-Splitter verwendet wurde, sind angezeigte physikalische Fehler auch dort im Server-Segment zu suchen (siehe Kapitel 5, »Switching und Mirror-Ports«); – im Server-Bereich an einem Mirror-Port stattfand, kann die örtliche Eingrenzung nicht ohne weiteres stattfinden, weil Messungen am Mirror-Port spezifische Probleme aufweisen (siehe Kapitel 5, »Switching und MirrorPorts«); – im Backbone zwischen verschiedenen Repeatern, Switches, Routern stattfand, gilt dem Server-Bereich entsprechend das Gleiche: Bei Verwendung eines Mirror-Ports ist die örtliche Eingrenzung problematisch, bei Verwendung eines Medium-Taps ist sie zuverlässig möglich.

Kontaktaufnahme/Verbindungsaufbau Kann etwas über den Stand der Kontaktaufnahme bzw. des Verbindungsaufbaus gesagt werden? •

Hat es zwischen zwei Rechnern (Kommunikationsendpunkten), die wegen eines Verdachts oder wegen eines Ausfalls überprüft werden, bereits Kontakt gegeben?

•

Wenn es keinen Kontakt gegeben hatte: Hat der Client Broadcasts gesendet: ja/ nein? Wenn ja: Kann ermittelt werden, welcher Server oder welcher Service gesucht wird? Ist es der zweite Rechner innerhalb der überprüften Paarbeziehung?

•

Wenn es bereits Kontakt gegeben hatte: Laufen die Zähler weiter hoch, oder bleiben sie stehen? Wenn sie weiterlaufen: Wie oft wird der Zähler um welchen Wert erhöht?

•

Wenn der Wert des Broadcast-Zählers sich in festen Intervallen mit einem festen Wert erhöht (etwa um den Wert 1 je Sekunde), so handelt es sich um Versuche der Kontaktaufnahme bzw. des Verbindungsaufbaus.

84

Erste Schritte

•

Wenn der Wert des Broadcast-Zählers sich dagegen unregelmäßig erhöht, sind dies eher Broadcasts, die mit dem aktuellen Fehler in der überprüften Paarbeziehung nichts zu tun haben, sondern unabhängig davon gesendet werden.

Einzelproblem vs. Gruppenproblem Betrifft das Problem nur einen einzigen Rechner oder betrifft es mehrere, und wenn es mehrere betrifft: gehören diese in irgendeiner Weise (physikalisch, logisch) zusammen? •

Hat ein Client bzw. Server nur mit einer bestimmten Gegenstelle Probleme, oder auch mit anderen?

•

Wenn Probleme nur mit einer Gegenstelle: Gibt es andere Sessions zur selben Gegenstelle, die weiterhin laufen, bei denen also weiter die Zähler hoch laufen?

•

Wenn Probleme auch mit anderen Gegenstellen auftauchen: Sind es alle Gegenstellen oder nur einige?

•

Wenn Probleme mit allen anderen Gegenstellen auftauchen, ist dies ein Hinweis auf Fehler in der Physik; so könnte das Anschlusskabel des Servers oder der entsprechende Switch-Port defekt sein oder der LAN-Adapter des Servers.

•

Wenn Probleme nur mit einer Gruppe von Gegenstellen auftauchen, so sind die Fehler weniger im Physical Layer zu suchen als vielmehr in den Netzwerkschichten darüber, etwa im Routing oder in den Applikationen.

•

Hat eine einzelne Station einen auffallend höheren Zählerstand bezüglich defekter Pakete als andere Stationen? Sind die Frames einer einzigen Station auffallend fehlerhafter als die Frames anderer Stationen?

•

Wenn ja, so ist dies ein Hinweis auf Fehler im Physical Layer im Anschlussbereich dieser einen Station.

•

Wenn nein, so sind die auftretenden Zählerstände insgesamt gleichmäßig verteilt oder bilden sich Gruppen?

•

Wenn sich alle Zählerstände bzgl. Paketfehler gleichmäßig verteilen, so sind die auslösenden Fehler ziemlich wahrscheinlich eher normale, zum alltäglichen Betrieb gehörende Kollisionen (Ethernet) oder Relaisschaltungen am Ringleitungsverteiler (Token-Ring).

•

Wenn sich die Zählerstände bzgl. Paketfehler auffällig in verschiedene Gruppen gliedern (die meisten mit niedrigem Zählerstand, ein paar aber mit sehr hohem Zählerstand), so spricht dies für einen Fehler eines Verteilers (Repeater, Switch) oder seines Uplink-Kabels oder der Buchsen links und rechts vom Uplink-Kabel (Kaskadierungskabel).

Kapitel 3 • Grundlagen der Methodik

85

Und jetzt: gezielte Messung mit dem Analyzer! Wenn auf diese Weise eine hinreichende Eingrenzung des Fehlers stattgefunden hat, wird gezielt gemessen. Hierzu müssen ggf. mehrere Analyzer zur Verfügung stehen.

3.3.8

Drei-Punkt-Messungen Es ist deutlich geworden, dass der Ort der Messung von überragender Bedeutung sein kann! Eine der systematisch wichtigsten Fragen, die an Messdaten zu richten sind, lautet: Entstand die Statistik •

im Client-Segement bzw. am Arbeitsgruppenverteiler

•

im Server-Segment, in der Server-Farm bzw. am Server-Switch

•

im Backbone zwischen Client und Server?

Im Idealfall liegen Messungen bzw. Statistiken von allen drei Orten vor. Dies führt zum Prinzip der Drei-Punkt-Messung: Sollte der Ort zu Beginn gar nicht eingrenzbar sein, muss an mehreren Punkten gleichzeitig gemessen werden: unmittelbar beim Client; unmittelbar beim Server; sodann auch im Netzwerk bzw. Backbone dazwischen, ggf. auch noch (als vierten Messpunkt) im WAN. Hier wird klar, dass die Investition in nur einen superteuren Analyzer schon im Konzept falsch ist – sofern das Budget beschränkt ist, wovon auszugehen sein dürfte. Es bringt weit mehr, mit drei Analyzern der unteren (2.000 bis 10.000 DM) oder mittleren Preisklasse (10.000 bis 20.000 DM) an drei verschiedenen Orten zu messen, als mit nur einem einzigen Gerät der hohen Preisklasse (20.000 bis 100.000 DM) an nur einem einzigen Ort. Der Hinweis auf RMON hilft hier nicht: RMON ist in aller Regel für das VorChecking gut; bei komplexen Fehlern aber hilft RMON nicht mehr zuverlässig genug, schon allein wegen des Zeitverlustes nicht. Das soll RMON nicht abwerten: Für Stichproben und Dauerüberwachung ist dies die richtige Technik. Im Falle wirklich harter Fehler aber müssen »echte« Analyzer eingesetzt werden – und im Idealfall eben drei Messrechner statt nur eines Analyzers.

3.3.9

Drei-Generationen-Messung Wenn schon drei Analyzer zur Verfügung stehen, lässt sich mit ihnen auch anders sinnvoll arbeiten als mit einer Drei-Punkt-Messung (s.o.), und zwar mit einer Drei-Generationen-Messung, die ihrerseits topografisch eine Ein-Punkt-Messung darstellt, da sie am selben Messpunkt erzeugt wird.

86

Erste Schritte

Bei einer Drei-Generationen-Messung werden die drei Messrechner wie folgt eingesetzt: 1. Der erste Analyzer ist auf langfristige Dauermessung eingestellt. Er läuft mal vielleicht eine halbe Stunde, mal vielleicht viele Stunden oder sogar den ganzen Tag durch. Filter werden hier grundsätzlich nicht gesetzt – oder nur in wirklich begründeten Ausnahmen. Der Grund hierfür erklärt sich aus der Verwendung der anderen zwei Analyzer, bei denen sehr gezielt mit Filtern gearbeitet wird. Während der zweite und der dritte Analyzer niemals alle Daten aufnehmen, ist der erste Analyzer die Rückversicherung für den Fall, dass ein wichtiges Ereignis mit den beiden anderen Analyzern nicht aufgenommen wurde, weil deren Filter das nicht zuließen oder weil sie sogar offline waren. 2. Der zweite Analyzer wird auf mittelfristige, gezielte Messung eingestellt. Er läuft vielleicht mal fünf Minuten, mal vielleicht ein halbe oder ganze Stunde. Filter werden hier sehr bewusst und sehr gezielt eingesetzt. Die Filtereinstellungen dieses zweiten Analyzers hängen wesentlich von den Arbeiten mit dem dritten Analyzer ab. 3. Der dritte Analyzer wird für kurzfristige, sporadische Messungen eingesetzt. Er dient dazu, kurze Stichproben zu nehmen, Ideen zu entwickeln bzw. Ideen nachzugehen. Aus den Ideen, die hier entstehen, bilden sich dann die Einstellungen für den mittelfristig laufenden zweiten Analyzer heraus. Grundsätzlich sollte dann, wenn der zweite Analyzer zwecks Übernahme der am dritten Analyzer entwickelten Filter offline genommen wird, der dritte Analyzer seinerseits online arbeiten, auch wenn der erste Analyzer seinerseits ständig mitläuft. Der Grund ist dieser: Sollte sich während der Umstellung am zweiten Analyzer etwas Wichtiges auf der Leitung ereignen, hilft es unmittelbar nicht, dass der erste Analyzer zuverlässig alles aufgenommen hat, da es systematisch oft unpassend ist, diesen zu unterbrechen, um an die Messdaten heranzukommen. Der erste Analyzer sollte im Normalfall den ganzen Tag durchlaufen und nie unterbrochen werden. Um aber bei Eintritt des nur sporadisch auftretenden Netzwerkfehlers schnell handeln zu können, ist es wichtig, dass immer einer der beiden Analyzer (Nr. 2 oder Nr. 3) mitläuft.

Kapitel 3 • Grundlagen der Methodik

87

Dieses Verfahren hat insgesamt seinen Grund darin, •

dass nach einem unvorhersehbaren, nur sporadisch auftretenden Fehler gesucht wird,

•

dass der Fehler also nicht reproduzierbar ist (nicht beliebig erregbar).

Für Fehler, die sehr wohl gezielt hervorgerufen werden können, gibt es andere Vorgehensweisen.

3.3.10 Reproduktion des Fehlers Ist ein Fehler jederzeit reproduzierbar, so ist die Analyse meistens schnell am Ziel. Es sollte daher wie folgt vorgegangen werden: Man sucht genau den Mitarbeiter im Hause, der am häufigsten unter dem Fehler leidet. Neben seinem Bildschirm wird der LAN-Analysator aufgebaut und angeschlossen. Wenn möglich, wird im Rechenzentrum ein weiterer Analyzer neben den Server gestellt, ggf. wird ein dritter in das Backbone dazwischen geschaltet. Sodann wird der/die Mitarbeiter/in aufgefordert, genau das zu tun, was für gewöhnlich im bekannten Fehler endet. Dies hat den Vorteil, dass die Aussagen des geschädigten Mitarbeiters zur Analyse herangezogen werden können; weiterhin ist durch gleichzeitige Sicht auf den Anwendermonitor sowie Analyzer-Monitor das Verständnis der Messdaten ungleich besser, als wenn man nur – und sozusagen »blind« – im RZ am Verteilerschrank säße. Hilfsweise kann die Kommunikation mit dem Anwender via Telefon erfolgen; dies ersetzt jedoch nicht den eigenen Blick auf den Anwendermonitor, da davon ausgegangen werden muss, dass der Anwender nicht alle Ereignisse korrekt interpretiert bzw. wiedergibt.

3.4

Die Windows-Registry Der LAN-Analyst ist oft entweder gezwungen, sich die Registry-Einstellungen von Windows-Maschinen anzusehen, die am Fehler beteiligt sind, oder er nimmt sogar Änderungen vor (was der Autor als Externer nie selber tut, sondern nur vorschlägt).

3.4.1

HKLM\System\CurrentControlSet\ exportieren Neben der Tätigkeit des LAN-Analysten sollten Mitarbeiter, die Zugang zu den WinNT-Servern bzw. den Client-PCs haben, die Registry-Daten kopieren und dem Analysten zur Verfügung stellen. Dies geschieht wie folgt: Es wird über Start\Ausführen der Registry-Editor »RegEdit« aufgerufen.

88

Die Windows-Registry

Abb. 3.4: RegEdit/Export von HKLM\System\CurrentControlSet (1)

Sodann muss entschieden werden, welcher Zweig exportiert werden soll: •

die gesamte Registry

•

nur HKEY_Local_Machine

•

nur HKEY_Local_Machine\System\CurrentControlSet

Das Wesentliche zur Datenkommunikation ist im letzten Schlüssel enthalten. Sodann wird die Export-Funktion aufgerufen:

Abb. 3.5: RegEdit/Export von HKLM\System\CurrentControlSet (2)

Kapitel 3 • Grundlagen der Methodik

89

Es wird der Name der Export-Datei abgefragt (die resultierende Datei endet auf *.REG). Weiterhin wird hier erneut die Wahl angeboten, statt eines Unterschlüssels bzw. Zweiges die gesamte Registry zu exportieren.

Abb. 3.6: RegEdit/Export von HKLM\System\CurrentControlSet (3)

Diese *.REG-Datei kann später beliebig untersucht werden.

3.4.2

Registry-Tools zum Durchforsten der *.REG Es gibt Shareware-Tools, die zum Durchforsten der exportierten Registry-Dateien geeignet sind. Auf der Beilage-CD-ROM ist das Programm »RegCheck« zu finden, das *.REGDateien einlesen und deren Inhalt darstellen kann. Wird eine Registry vollständig importiert, können mehrere 10.000 Schlüssel und Parameter in der *.REG-Datei enthalten sein. Ein kleiner Text-Editor wie der NotePad von Windows kann diese Menge schon nicht mehr einlesen und darstellen. Entweder nimmt man dann ausgewachsene Textverarbeitungsprogramme wie WinWord oder eben ein Registry-Tool. RegCheck hat den Vorteil, dass es nicht die Registry direkt »anfasst«, sondern nur mit den Export-Dateien im Format *.REG arbeitet. Der dargestellte Registry-Path ist zugleich gewissermaßen »des Pudels Kern« für dieses Buch.

90

Die Windows-Registry

Abb. 3.7: Beispiel einer Registry-Darstellung mit RegCheck

WinNT Registry: HK_Local_Machine\System\CurrentControlSet\Services

3.4.3

Systemsteuerung\Netzwerk: Vade retro! Der vielleicht hilfreichste Satz des römischen Herrschers war ein herrisch-mürrisches »Vade retro!« (Weiche zurück!), wenn er niemanden an sich heranlassen wollte. Dies sollte auch Ihre Einstellung gegenüber der Windows-Systemsteuerung im Bereich »Netzwerk« sein. Merke: •

Windows-Systemsteuerung? Das sind alles nur mehr oder weniger unverbindliche Empfehlungen oder Hinweise.

•

Kein Windows-Rechner wird es sich je nehmen lassen, am Ende doch zu tun, was er will.

•

Und schon gar nicht wird er Ihnen alles zeigen, was er so drauf hat.

•

Nur Bruchteile dessen, was sich so in den LAN/WAN-Protokollen herumfummeln lässt, wird auch in der Systemsteuerung offenbar.

•

Seine Geheimnisse bewahrt der Windows-Rechner allein in der Registry auf: Nur dort ist die volle Wahrheit zu finden!

Das ist das »Ceterum censeo ...« des Autors.

Kapitel 3 • Grundlagen der Methodik

3.5

91

Deutung der Ereignisse und Messdaten Die erste Regel des externen Analysten lautet: Höre dir an, was dir der Kunde zu sagen hat, aber misstraue, wo es nur geht! Zu dem, was weiter oben bereits ausgeführt wurde, sei gesagt:

3.5.1

Misstraue dem Kunden bzw. Anwender! Dies hat Gründe: Schnell lässt man sich durch die Erzählungen des Kunden – ihrerseits vorgetragen im Brustton der tiefsten Überzeugung – in die Irre führen. Es ist doch so: Wenn der Kunde wirklich verstanden hätte, was da auf der Leitung geschieht, hätte er den Analysten wohl kaum rufen müssen. Also: Aufgepasst! Insbesondere muss Misstrauen herrschen gegenüber »Erkenntnissen« des Kunden, die er aus Konsolenmeldungen der Server und Router hat oder aus Fehlermeldungen der Client-PCs.

3.5.2

Misstraue den Fehlermeldungen der Rechner! Ein Beispiel: Eine bei OS/2 und MS-Windows (3.x,95,98,NT) beliebte Meldung lautet: »Von Gerät Netzwerk kann nicht gelesen werden.« Schon ruft der Mitarbeiter im RZ an und sagt: »Ich habe keine Verbindung zum Netzwerk. Meine Ethernet-Karte ist kaputt.« Idealerweise wird im RZ gleich weitergedacht: Entweder ist tatsächlich die Ethernet-Karte kaputt oder eben das Kabel, der Stecker, die Buchse, der Verteiler. Dabei hat doch nur – beispielsweise – ein Server vorübergehende Überlast gemeldet oder ein Router den Umstand, dass er nicht zuständig ist (sondern ein Nachbar-Router). Beim Weg durch die verschiedenen Protokoll- bzw. Treiberinstanzen wird fast jede objektiv korrekte Fehlermeldung derart grausam verstümmelt, dass am Ende nichts weiter übrig bleibt als: »Von Gerät Netzwerk kann nicht gelesen werden.« Insbesondere die äußerst genauen Fehlermeldungen von Routern via ICMP (Internet Control Message Protocol) und NetWare-Servern via NCP (NetWare Core Protocol) werden regelmäßig falsch ausgegeben – oder eben gar nicht.

92

Deutung der Ereignisse und Messdaten

So kommt es oft zu unbegründeten Vermutungen über Fehler in der NetzwerkHardware. Beispiel Ethernet: Da jeder Ethernet-Administrator weiß, dass es Kollisionen gibt, und dass bei einer Überlastung des Netzes und bei der damit ansteigenden Zahl der Kollisionen auch Client-Server-Sessions »sterben« können, fällt der Verdacht sofort dort hin, wo er durchaus nicht hingehören muss. Auch hier wird wieder sichtbar, dass über alle Netzwerkschichten und Protokolle hinweg gemessen und interpretiert werden muss.

3.5.3

Wertvolle vs. wertlose Statistiken Es soll nicht behauptet werden, dass die Statistiken der Messgeräte nicht stimmen würden. Es soll aber darauf hingewiesen werden, •

dass man Statistiken richtig lesen muss,

•

dass man aus einer Vielzahl von Statistiken die für den aktuellen Zweck richtigen heraus finden muss.

Dies soll an einem der wichtigsten Beispiele überhaupt erläutert werden: Allgemein wird schnell und gerne behauptet: »Das Netzwerk ist langsam.« Diese Aussage hört jeder Netzwerker mehrfach am Tag. Dann ist schnell die Rede davon, die Netzlast sei zu hoch, und überhaupt müsse man wieder aufrüsten (Gigabit, Terabit, ...). Jetzt also muss Statistik her! Schon wird das LAN-Monitoring angeworfen und heraus kommt dabei wahlweise folgendes: Ein buntes Statistik-Placebo ... Das zweifellos schönste, bunteste und zugleich sinnloseste Gimmick der Analyzer ist der Tachometer (siehe Abb. 3.8). Zwar wird hier hübsch mit je einem eigenen Zeiger unterschieden zwischen ... •

aktuellem Wert

•

Durschnittswert

•

Spitzenwert

... aber das sagt alles schlicht nichts über das Netzwerk aus. Es sind wirklich nur schöne, bunte Bilder, die sich auf dem Messestand des Herstellers ganz gut machen, damit mal jemand stehen bleibt. Die CeBIT ist jedes Jahr voll davon. Was diese Art der Darstellung so wertlos macht, ist der völlige Verlust der zeitlichen Komponente.

Kapitel 3 • Grundlagen der Methodik

93

Abb. 3.8: Die berühmt-berüchtigte Tachometeranzeige

... und sein Gegenstück Eine durchdachte Kurvendarstellung ist dagegen sehr viel aussagekräftiger: Im Beispiel der Abbildung 3.9 sind die Werte für »Netzlast« und »Paketfehler« überbzw. nebeneinander gelegt – mit einem erheblichen Erkenntniswert. Wenn die Fehlerspitzen sich zur selben Zeit ereignen wie die Lastspitzen, so sind die Fehler eine Folge dieser erhöhten Netzlast, da sich ganz natürlich dann auch die Zahl der Kollisionen erhöht – sofern es sich dabei um Shared Media Ethernet handelt. Tauchen die Fehlerspitzen unabhängig von Lastverlauf auf, so ist dringend ein Fehler in der Netzwerkphysik zu vermuten. Tauchen die Fehlerspitzen zwar abhängig vom Lastverlauf auf, aber zwischen Switches, so sind dies eben nicht normale Kollisionen, sondern vermutlich Fehler, die einer der Switches selber aktiv erzeugt.

94

Deutung der Ereignisse und Messdaten

Abb. 3.9: Darstellung der Verkehrsstatistik mit Kurven im Zeitfenster

Alle diese Erkenntnisse wären aber trotz der an sich guten Kurvendarstellung nicht zu gewinnen, wenn nicht beide Kurven zugleich angezeigt würden! Es zeigt sich also: •

Es gibt gute Statistiken mit guter Darstellung.

•

Es gibt gute Statistiken mit schlechter Darstellung.

•

Es gibt schlechte Statistiken mit guter, dann aber sinnloser Darstellung.

•

Es gibt schlechte Statistiken mit schlechter Darstellung – aber bunten Bildern!

Das alles spielt sich ab in einer Dimension, an die Winston Churchill gar nicht dachte, als er seinen berühmten Spruch tat, dass er nur der Statistik glaube, die er selber gefälscht habe. Die konsequente Fortentwicklung des Churchill’schen Zitats lautet: »Lasse nur mal einen Grafiker sich an der Statistik austoben, und es ist zukünftig ohne jeden weiteren Belang, ob diese gefälscht worden war oder nicht!« Eine biedere Standardstatistik ... Das zweite Beispiel ist ähnlich angelegt wie das erste, nur deutlich unauffälliger. Eine völlig korrekte und unverzichtbare Statistik ist die Ausgabe von •

aktuellem Wert

•

Durschnittswert

•

Spitzenwert

Kapitel 3 • Grundlagen der Methodik

95

für die Faktoren •

Netzlast pro Sekunde (verbrauchte Sendezeit pro Sekunde)

•

Pakete pro Sekunde

•

Oktetts (Bytes) pro Sekunde

•

defekte Pakete pro Sekunde

•

Broadcast-Pakete pro Sekunde

•

Multicast-Pakete pro Sekunde

So ziemlich jedes Produkt, das Netzwerkbeobachtung betreibt, gibt diese Zahlen aus.

Abb. 3.10: Statistik bezüglich der Netzlast pro Sekunde

Fällt Ihnen etwas auf? Nein? Doch, vermutlich schon, aber erst auf den zweiten Blick: Was besagt denn eigentlich diese Zahl »Utilization Peak = 83,9%"? Richtig! Sie besagt – nichts. Wie das? Sehen wir genauer hin: Einerseits wird eine durchschnittliche Netzlast pro Sekunde von 15% angegeben, andererseits eine Spitzenlast von rund 84%. Um diese Zahlen auch nur annähernd sinnhaft deuten zu können, bedürfte es zweier zusätzlicher Angaben, die hier aber völlig fehlen: •

der Beobachtungszeitraum

•

weitere Ergebnisse zu diesen Faktoren zu anderen Zeitpunkten.

Ein guter Analyzer ermöglicht es, mit schnellem Blick die bisherige Messdauer zu ermitteln:

Abb. 3.11: Zeitanzeige in der Statuszeile von LANdecoder32

96

Deutung der Ereignisse und Messdaten

Aha. Also seit 26 Minuten lief die Messung. Ist das jetzt lang oder kurz, wenn wir auf den Wert »durchschnittliche Netzlast = 15%« sehen? Wie sollen wir das deuten? Wenn man das Netz, die Applikationen und das gewöhnliche Arbeitsverhalten der Teilnehmer nicht kennt, reichen auch jetzt die Daten nicht aus, um eine halbwegs sinnvolle Deutung der Zahlen vorzunehmen. Woran hängt es denn jetzt noch? Was uns fehlt, sind die Werte von anderen Zeitpunkten (sog. »Schnappschüsse«), oder aber dieselben Werte, nur über einen längeren Zeitraum, also längerfristig gemittelt. Wir können nämlich bis dato nicht wissen, ob der einmal erreichte Spitzenwert von ca. 84% ein einmaliger Ausreißer war und die nächsten Spitzenwerte dahinter so etwa bei 20 oder 30% lagen, oder ob permanent Spitzen im Bereich von 70 oder 80% vorkommen. Selbst die Zahl von rund 15% Durchschnittslast kann uns da nicht weiterhelfen. Klar: Auf den ersten Blick könnte man annehmen, dass der geringe Wert von 15% nahe legt, dass die weiteren Spitzen niedrig sein müssten. Das aber ist eine unbewiesene Annahme! Denn nicht beantwortet bis zum gegebenen Zeitpunkt ist die Frage, ob die Datenmenge, die zu dem Wert von 15% Durchschnittslast führt, in gleichmäßigem Datenfluss entstand oder ihrerseits in höheren Spitzen. Hinweis Wir müssen übrigens weiterhin zur Kenntnis nehmen: Auch die Statistik-proSekunde ist nur eine gemittelte Statistik. Während eine einzelne Sekunde bei 10 Mbps Ethernet noch halbwegs aussagekräftig war (»nur« max. 14.400 Pakete pro Sekunde), so ist schon bei Fast Ethernet (mit max. 144.000 Paketen pro Sekunde) schon genügend Raum für eine sehr uneinheitliche Verteilung der Daten über die Sekundengrenzen hinweg. Wir brauchen also mehr als nur den Sekundenwert. ... und ihre unverzichtbare Ergänzung Wenn wir neben die Statistik-pro-Sekunde eine zweite legen, nämlich die Statistik-pro-Minute, wird das Ganze schon klarer. Jetzt können wir sicher sagen: Wenn die durchschittliche Spitzenlast pro Minute ca. 30% beträgt, dann dürfte der Wert von ca. 84% pro Sekunde ein eher seltener Ausreißer gewesen sein. Denn würden sich Lastspitzen im Bereich von 70 oder 80% häufiger ereignen, so würde der Wert »Utilization Peak per Minute« deutlich höher ausfallen.

Kapitel 3 • Grundlagen der Methodik

97

Abb. 3.12: Statistik bezüglich der Netzlast pro Minute

Im aktuellen Fall aber ist es so, dass im Beobachtungszeitraum von rund 26 Minuten der gemittelte Spitzenwert pro Minute nur 29% beträgt, und deswegen müssen in allen anderen, vorherigen Minuten (vor der 26. Minute mit dem Mindestspitzenwert von 83,9%) die Werte umso niedriger gewesen sein. Also kann die Belastung des Netzes mit Verkehrsspitzen so arg nicht gewesen sein. Der Wert von 18,9% für die durchschittliche Netzlast pro Minute (gemittelt auf die bisherigen 26 Minuten) bestätigt diesen Befund. Auch hier also hat sich gezeigt, dass die gleichzeitige Erfassung bzw. Betrachtung verschiedener, aber verwandter Statistiken von erheblichem Belang sein kann. Und so sieht das Ganze dann tatsächlich aus (Beispiel):

Abb. 3.13: Statistikfenster im LANdecoder32

98

Statistik in Intervallen: Snapshots

Ganz nebenbei wird hier ersichtlich, dass es sinnvoll ist, mehrere Monitore mit verschiedenen Grafikanzeigen parallel laufen zu lassen. Die hier besprochenen Formen von Statistik können online bei der Suche nach akuten Fehlern helfen. Die folgenden Statistiken dienen der langfristigen Beobachtung des Netzwerks und sollten zur ständigen Pflege gehören.

3.6

Statistik in Intervallen: Snapshots Um auch rückwirkend alle notwendigen Aussagen anhand klarer Daten machen zu können (und um nicht im Kaffeesatz lesen zu müssen), sollten die wichtigsten Kennzahlen der Netzwerkstatistik in festen Intervallen in Tabellen geschrieben werden, damit sie später wieder sichtbar gemacht werden können. Solche Dauerstatistiken werden oft Snapshots und ihre Ergebnisse Baselines genannt. Eine mögliche Dauererfassung der Netzwerkstatistiken könnte wie folgt eingestellt werden (Abbildung 3.14):

Abb. 3.14: Festlegung der Ausgabedateien für Dauerstatistiken

Jetzt muss noch das Intervall festgelegt werden, in dem die Statistikwerte in die Tabellen geschrieben werden (Abbildung 3.15). Wenn jeweils das Erfassungsintervall abgelaufen ist, werden die Zählerwerte der angewählten Statistiken in die Tabellen (bzw. in die Dateien) geschrieben und sodann im Programm wieder auf Null gesetzt.

Kapitel 3 • Grundlagen der Methodik

99

Abb. 3.15: Festlegung des Erfassungsintervalls für Dauerstatistiken

So kann jederzeit der Ereignisverlauf wieder rekonsturiert werden; mit MS-Excel oder anderen Programmen können dann wieder Kurvendarstellungen erreicht werden, wie sie auch schon online sichtbar sind (Abbildung 3.16).

Abb. 3.16: Langzeitstatistiken in Kurvendarstellungen

Online-Statistik vs. Offline-Statistik Bei solchen Kurvendarstellungen wählt man bei Online-Statistiken für gewöhnlich Zeitfenster von jeweils einer Minute oder eine Stunde. Bei den Offline-Statistiken, die aus den Intervalltabellen entstehen, wären Intervalle von vielleicht 10 oder 15 Minuten sinnvoller: Das Minutenraster wäre vielleicht zu eng, das Stundenraster vielleicht zu grob. Hier muss die Erfahrung entscheiden, welches Zeitintervall günstig ist.

100

Trace-Bibliotheken – ein wertvolles Gut!

Die Aufbereitung und Aufbewahrung Diese Statistiken sollten, durchaus auch optisch gut aufbereitet, ausgedruckt und abgelegt werden; ggf. sollten sie über einen Intranet-Webserver laufend publiziert werden, damit alle Dienste des Hauses darauf Zugriff haben (auf die nachbearbeiteten Statistiken, nicht auf die Geräte!). Auch sollten diese Statistiken dem Vorgesetzten vorgelegt und von diesem abgezeichnet werden. Die LAN-Techniker trifft oft der Vorwurf, sie hätten nicht früh genug gewarnt, wenn das »Netz mal wieder zu langsam« war. Gegen diesen ziemlich unfreundlichen, aber oft zu hörenden Vorwurf kann sich der Techniker am besten auf die beschriebene Weise zur Wehr setzen. Außerdem helfen solche Statistiken auch dem Vorgesetzten des LAN-Technikers, notwendige Beschaffungen besser und frühzeitig zu begründen. Somit kommen wir zum grundsätzlichen Erfordernis des Archivierens von Messdaten.

3.7

Trace-Bibliotheken – ein wertvolles Gut! Zur Methodik des Analysten gehört, dass er »gut« von »schlecht« unterscheiden kann. Das aber ist nur möglich, wenn der Normalfall so gut bekannt ist (gewissermaßen im Gehirn »fest eingebrannt«), dass eine Abweichung davon sofort erkannt wird. Dies setzt voraus, •

dass der Analyst regelmäßiges Training hat und

•

dass der Analyst über umfangreiche Bibliotheken mit Messdaten (engl. »Traces«) verfügt, um im Zweifel vergleichen zu können.

Ein externer Techniker (Dienstleister) sollte eine gute Sammlung von CD-ROMs immer in seinem »Notarztkoffer« dabeihaben. Ein interner Haustechniker sollte es sich angewöhnen, seine Messergebnisse auf einem hauseigenen Intranet-Webserver zu publizieren. Dies hat viele Vorteile: •

Die Bibliotheken, welche für viele Vorgänge den jeweiligen Normalfall dokumentieren, sind stets verfügbar.

•

Die Bibliotheken, welche die früher einmal erkannten und behobenen Fehler dokumentieren, helfen, (a) denselben Fehler nicht zweimal zu machen, (b) die Vorgehensweise im Fehlerfalle nicht erneut entwickeln zu müssen.

In Abschnitt 3.6 war bereits von Statistikdaten die Rede, die es aufzubereiten und aufzubewahren gilt.

Kapitel 3 • Grundlagen der Methodik

101

Dies ist auf Capture Data ebenfalls anzuwenden: Beispielhafte Traces oder solche, die Fehler enthalten, sind aufzubewahren und in Auszügen mittels IntranetWebserver bekannt zu machen. Diese Art der Publikation hilft allen EDV-Diensten im Hause, nicht ständig das Rad neu erfinden zu müssen – Rückgriff auf Messdaten zu allen Bereichen der EDV, etwa Datenbankabfragen, Abgleich von Name-Server-Tabellen etc. gehören in die Hand aller, deren Arbeitsauftrag damit zu tun hat. Das Online-Publishing, auf das hier abgezielt wird, ist nicht nur eine permanente Daueraufgabe, sondern zudem ein wichtiges Mittel im Notfall.

3.8

Online-Publishing im Ernstfall Der Autor geht im Ernstfall sogar noch oft einen Schritt weiter: Er macht einen seiner Messrechner zum Intranet-Webserver und publiziert die Messergebnisse so, wie sie anfallen. Den Mitarbeitern im Hause des Kunden wird der Zugriff hierauf eingerichtet, und die Seite wird allen bekannt gemacht. Sodann werden alle aufgefordert, die darin aufgeworfenen Fragen zu klären. Dies sind oft einfache, aber wichtige Dokumentationsaufgaben. Es muss ja berücksichtigt werden, dass im Hause des Kunden oft ein erschreckender Mangel an Dokumentation herrscht. Oft erfahren die hauseigenen Techniker erst durch den externen Analysten, was sie da eigentlich im Netz bzw. auf der Leitung haben. Es ist schon vorgekommen, dass erst durch die Messung klar wurde, dass Switches als Repeater arbeiteten, weil die Konfiguration der Geräte nicht dokumentiert war; oder dass Router ungewollt im Kreisverkehr gekoppelt waren, weil die Verkabelung niemals dokumentiert worden war. Wenn im Ernstfall extremer Zeitdruck herrscht, kann kein Einzelner alles auf einmal selber leisten. Auch der beste Netzwerk-Guru kann das nicht. Die Kunst besteht dann darin, die richtigen Arbeitsaufträge zu vergeben. Die beste Unterstützung hierzu ist ein Intranet-Webserver, den man selber kurzfristig aufsetzt. Alle rücklaufenden Ergebnisse werden dann sofort in die Webseiten hineingepflegt; so hat das ganze Team beste Aussichten, möglichst koordiniert und ohne Reibungsverluste voranzukommen. Dass diese Arbeit für einen externen Analysten zu viel sein kann, liegt auf der Hand. Entsprechend fahren aus dem Hause des Verfassers je nach Vorankündigung zwei oder sogar drei Mitarbeiter zum Kunden, um möglichst synchron die größtmögliche Wirkung zu erzielen.

102

3.9

Psychologie und Nervenstärke!

Psychologie und Nervenstärke! Zuletzt sei darauf verwiesen, dass der externe Techniker in einer besonderen Situation ist, der er gerecht zu werden hat bzw. die er für seine Zwecke nutzen sollte. Die folgenden Überlebensregeln für den Notfall sollen helfen. •

Neutralität bewahren! Die meisten schweren Fehler sind zwar unmittelbar technisch bedingt, aber mittelbar in Fehlern der Arbeitsorganisation und Arbeitsteilung im Hause des Kunden zu suchen. Man trifft als Externer also nicht nur auf einen technischen Defekt, sondern auch auf ein organisatorisches Umfeld, das oft davon geprägt ist, dass sich Abteilungen im Hause des Kunden schon seit Jahren gegenseitig befehden, sich gegenseitig Dokumentationen vorenthalten etc. Als Externer hat man die einzigartige Gelegenheit, Türen zu öffnen (z.B. zu diversen »geheimen Kommandosachen«, also bislang im Hause nicht frei zugänglichen Dokumentationen), die sich die hauseigenen Techniker anderer Abteilungen nicht hatten öffnen können.

•

Als Vermittler auftreten! Es sollte Aufgabe des Externen sein, alle diejenigen an einen Tisch zu bringen, deren Verantwortlichkeiten aktuell im Fehlerfalle berührt sind. Die ggf. vorhandenen Feindschaften müssen schnell und zuverlässig überwunden werden – wenigstens für den Moment. Hier ist hilfreich, bei einer solchen »Elefantenrunde« die notwendigen Arbeitsaufträge zu verteilen – etwa zur Nacharbeitung von Dokumentationen bzw. zur Beschaffung notwendiger Information. Das Online-Publishing, das oben beschrieben wurde, ist sodann nicht nur für das eigentliche Dokumentieren wichtig, sondern hilft auch, die Leute wieder zueinander zu führen.

•

Zeigen, dass auch der Helfer Hilfe braucht! Oft treten die Fehler nur bei wenigen, bestimmten Anwendern auf. Dann ist es messtechnisch sehr hilfreich, unmittelbar am Arbeitsplatz eines solchen Anwenders zu messen (s.o.). Dann aber sollte man als Externer in der Lage sein, den entsprechenden Mitarbeiter davon zu überzeugen, dass es eine gute Tat ist, einen halben oder ganzen Tag dafür zu opfern, »Versuchskaninchen« zu sein. Da Anwender oft den Netzwerkleuten skeptisch gegenüberstehen (je nach individueller Erfahrung), sollte man immer zu verstehen geben, dass man für alle da ist und allen hilft, nicht nur ausgesuchten Wenigen.

Kapitel 3 • Grundlagen der Methodik

103

Die Hilfsbereitschaft nur einer einzigen Sekretärin kann entscheiden, ob ein Störfall in Stunden oder Tagen gelöst werden kann – entsprechend sollte man sich in seinem Verhalten auf die Situation einstellen. •

Niemals unter Druck setzen lassen! Die Ursache für das messtechnische Scheitern der hauseigenen Analysten liegt oft darin begründet, dass sie nicht in Ruhe und nicht systematisch vorgehen können – eben, weil der Druck zu groß ist, der auf ihnen lastet bzw. der auf sie ausgeübt wird. Es ist völlig verständlich, dass bei einem Fehler, der pro Stunde mehrere Zehntausend oder Hunderttausend Mark kostet, jeder weiß, wie groß die Verantwortung ist, und schnell wird der Druck sprichwörtlich von-oben-nachunten abgeleitet. Mit einer solchen Situation ist aber oft der hauseigene Techniker überfordert. Hier die Ruhe zu bewahren und sich nicht vom systematischen Vorgehen abbringen zu lassen, ist erste Analystenpflicht, zumal dann, wenn es sich um einen externen Dienstleister handelt.

Diese kleinen Regeln mögen nicht alles aufzählen, was wichtig ist, sind aber doch unverzichtbare Forderung an jeden – zumindest externen – Analysten, wenn der Notfall eingetreten ist. Zusätzliche Hinweise zu diesem Thema sind im Kapitel »Die Notfallmessung« enthalten.

3.10

Vorbeugen ist besser als Bohren Schwierig wird Netzwerkanalyse dann, wenn ein Fehler (bzw. Ereignis) nicht auf lediglich eine einzige Ursache zurückgeführt werden kann. Tatsächlich handelt es sich bei den »ultraharten« Fehlern, die der Autor regelmäßig zu Gesicht bekommt, um multikausale Ereignisse mit einer langen Entwicklungsgeschichte. Dies muss erläutert werden. Der Autor und seine Mitarbeiter werden in aller Regel dann gerufen, wenn alle anderen Maßnahmen und Dienstleister nicht mehr helfen konnten. In diesen Fällen stellt sich überwiegend heraus, dass viele, viele kleine Symptome (= Abweichungen von der Norm) zu finden sind, wobei jedes einzelne Symptom für sich noch keinen Fehler auslösen muss. Im Laufe der Jahre wird hier umgebaut, dort ein neuer Treiber installiert, hier wieder ein neues Betriebssystem in Dienst genommen, dort ein Router gegen den anderen ausgetauscht. Damit schleichen sich regelmäßig kleine ... sagen wir: kleine »Unschärfen« ein, kleine »Macken«, bei denen die verwendeten Protokolle nicht ganz korrekt bedient werden oder die Konfigurationen nicht ganz sauber sind.

104

Permanente Qualitätssicherung

Diese »Macken« reichen von falsch gesetzten Timern (etwa TCP: »Wann bloß soll ich ein Paket als verloren ansehen und die Wiederholung starten?«) und falschen ARP-Table-Entries (etwa: »Wieso meldet sich der andere eigentlich nicht, wenn ich ihn mit dieser MAC-Adresse rufe?«) bis zu falschen Protokollanweisungen (etwa: »Okay, ich habe die NFS-Verbindung über UDP schon, das hindert mich aber nicht daran, sie unter TCP trotzdem noch parallel dazu aufzubauen«). Das kann lange gut gehen. Irgendwann bringt aber ein einziger zusätzlicher Fehler die ganzen Domino-Steinchen ins Kippen. Heißt: Ein einziges zusätzliches Protokollereignis kann dann ausreichen, um auf einmal viele oder alle dieser »alten Macken« zu verbinden und ganze Netzwerke außer Betrieb zu setzen. Alles das hat der Autor schon mehrfach erlebt. Die Folgerungen aus diesen Erkenntnissen sind: Protokollanalyse ist nicht nur für den Schadensfall da; sie hat ständig stattzufinden. In jedem Falle muss sie vor, während und nach einem Eingriff ins Netzwerk stattfinden (neue Router, Server, Treiber etc.). Es darf niemals nur eine einzelne Schicht isoliert betrachtet werden. Es müssen die Ereignisse/Auffälligkeiten/Symptome aller Schichten und aller Rechner bzw. Komponenten gleichzeitig gesehen und in ihren Wechselwirkungen erkannt werden. Da hiermit sowohl die meisten Techniker als auch die meisten Analysewerkzeuge überfordert sind, wurden die sog. Expertensysteme (Expert Diagnosis) erfunden. Leider nehmen auch diese High-Tech-Erzeugnisse die Schichten und Ereignisse überwiegend isoliert in den Blick; das Erkennen komplexer, verwobener Fehlerstrukturen wird dadurch nicht unbedingt erleichtert. Und doch: Das verfügbare Instrumentarium sollte unbedingt ständig und gezielt eingesetzt werden. Und das Ziel muss lauten:

3.11

Permanente Qualitätssicherung Netzwerkanalyse dient bei bester Anwendung und bester technischer Ausstattung •

der ständigen Dokumentation,

•

der Revisionsfähigkeit des Netzwerkes,

•

der Vorbeugung,

•

dem notwendigen Training für den Notfall.

3.11.1 Kosten Wer immer über die Kosten von Analysewerkzeugen oder Netzwerk-Management-Komponenten klagen möchte, sollte sich klarmachen, dass ein richtiger Einsatz dieser Technik schon binnen kürzester Zeit das dafür angelegte Geld wieder hereinholt.

Kapitel 3 • Grundlagen der Methodik

105

3.11.2 Einsparungen Schon allein die Kostenersparnisse, die erreicht werden können, übertreffen die Ausgaben für die Analyse bei weitem: In vielen, wenn nicht den meisten Unternehmungen wird in oft schon unverständlicher Form eine gigantische Überrüstung betrieben, vorrangig an zwei Orten: bei den Servern und im LAN-Backbone. Die Switches sollen immer schneller sein und die Server auch. Dagegen ist ja nichts einzuwenden: Wenn aber der Flaschenhals tatsächlich ganz woanders lag, nutzt(e) auch die teuerste Neuanschaffung bei Servern und Switches nichts. Wer dagegen regelmäßig mit Sachverstand auf die Leitung blickt, weiß genau, wo die Leistungsverluste und die Leistungsreserven versteckt sind. Das wiederum erlaubt fortlaufendes Tuning, fortlaufende Qualitätssicherung – und es spart Kosten. Am Ende aber kommt es nur auf eines an:

3.11.3 Garantierte Verfügbarkeit Was für ein Unternehmen am Ende allein zählt, ist die sichere Verfügbarkeit der EDV. Bei allen Klagen über die Kosten der EDV ist es doch so, dass die Ausfallkosten im Zweifel noch schlimmer sind als die laufenden Kosten fürs Datennetz. Spätestens in Fabriken, deren Fließbänder stillstehen, wird das klar. Wer aber eine an 100 % heranreichende Verfügbarkeit garantieren will, muss •

messtechnisch vorbeugen und

•

die Messtechnik selber permanent verfügbar machen.

Alles andere ist daneben schon eher nachrangig. Bei der Netzwerkanalyse handelt es sich also um einen strategischen Unternehmensdienst, der niemals vernachlässigt werden darf. So, wie es für die Finanzen ein Controlling gibt, sollte die LAN-Analyse auch eine ständige Kontrolle der Rechner und ihres Datenflusses sein. Es gehört also auch zur Aufgabe des hausinternen Analysten, diese Sichtweise zu vertreten und populär zu machen – letztlich ist genau dies sein Auftrag. »Klappern gehört zum Handwerk« – und mit diesem »Klappern« fängt die gute Messmethodik schon an: Denn nur wer beizeiten vorgebaut und das Geld für die richtigen Messwerkzeuge locker gemacht hat, kann im Notfall auch wirkungsvoll handeln und helfen.

106

Permanente Qualitätssicherung

Der bereits weiter vorne beschriebene Intranet-Webserver zur permanenten Veröffentlichung von Messdaten dient u.a. diesem Zweck: Wenn über Jahre die wöchentlichen Statistiken und Stichproben veröffentlicht werden, wird dies nach und nach im Unternehmen zur Kenntnis genommen; der Wert dieser Tätigkeit wird spätestens bei Nachweis der dadurch erreichten Einsparungen von niemandem mehr ernstlich in Zweifel gezogen werden. Ein bisschen Werbung in eigener Sache kann also nicht schaden.

Kapitel 4 Statistik vs. Analyse 4.1 4.2 4.3 4.4

Frage und Antwort: Welche Messung? Zweiter Anlauf Dritter Anlauf und letzte Klärung Das Ergebnis

108 115 121 122

108

Frage und Antwort: Welche Messung?

Mit einem unserer Kunden führte ich im Dezember 1998 eine beispielhafte Korrespondenz via E-Mail, um ihm verständlich zu machen, warum bestimmte Formen der LAN-Analyse, wie er sie sich vorstellte, ungeeignet sind, zu den gewünschen Aussagen zu kommen. Er fragte nach »Lasttest« und »Statistik«, ohne eigentlich zu wissen, was er da meinte. Hätten wir den Auftrag ohne Klärung angenommen, hätte es am Ende nur eine Enttäuschung geben können. Nach der Anfrage des Kunden die kommentierte Antwort, die ich unserem Kunden schickte. Der Text des Kunden ist jeweils in Kästen gesetzt, die Antworten stehen als Einschübe jeweils dazwischen. Danach folgen noch eine weitere Rückfrage des Kunden sowie meine abschließende Antwort darauf.

4.1

Frage und Antwort: Welche Messung? Sehr geehrter Herr Walther, wir haben heute mit einem Ihrer Techniker gesprochen und ihn um ein Angebot gebeten. Bei einem unserer Kunden soll ein Lasttest durchgeführt werden. Das Netzwerk besteht aus mehreren Servern, die über NT 4.0 verbunden sind. Die Netzwerkkomponenten sind allesamt von 3Com. Damit Sie sich ein Bild machen können, führe ich nachfolgend den Inhalt des Tests auf. Switch-Durchgangstest Für diese Messung wird von einer Station aus eine Netzlast generiert und von einer anderen Station empfangen. Der Netzlastgenerator muss in der Lage sein, bis zu 95% Netzlast zu erzeugen.

Frage: Worüber reden wir? Vermutlich Ethernet, aber 3COM verkauft auch Token-Ring. Da Sie hinsichtlich der Messungen von einer Paketgröße von 64 Byte sowie von Kollisionen sprechen, ist wohl von Ethernet die Rede. Ist es 10 Mbps oder 100 Mbps Ethernet? Die empfangende Station muss die Netzlast, die Kollisionen und die Fehler zählen und an die Adressen zu den jeweiligen Paketen eintragen.

Der von uns verwendete Traffic Generator sendet nur an ein und dieselbe Zieladresse. Weiterhin ist nicht klar, ob es überhaupt Kollisionen geben kann; Gründe: Es könnten flächendeckend Switches eingebaut sein, die Kollisionen ausschliessen. Bei Switches kann es allenfalls Paketverlust durch Buffer Overflow geben (sofern der Switch o.k. ist). Fehler wären bei Switches nur durch Verfälschung der Pakete gegeben (möglich, aber sehr selten).

Kapitel 4 • Statistik vs. Analyse

109

Sollten Switches vorhanden sein, ist eine Messung eher darauf ausgerichtet, die Verzögerung (Latenzzeit) zu messen, die durch die Verarbeitung in den Switches erfolgt. Bei Switches, die zwischen IN-Port und OUT-Port unterschiedliche Geschwindigkeiten haben, erfolgt zwingend Store-And-Forward, also volle Zwischenpufferung. Je nach Architektur des Switches kann dies schnell oder auch weniger schnell erfolgen. Sollten Repeater verwendet werden, können selbstverständlich Kollisionen auftreten. Ebenfalls könnten (sehr selten) Repeater (oft zweideutig als »Hubs« bezeichnet – wie bei Ihnen unten) ebenfalls Verfälschungen bewirken – womit aber kaum zu rechnen ist. Im Folgenden sprechen Sie zwar selber von Switches, aber es ist nicht dargelegt, ob die Switches an allen Knotenpunkten stehen (bzw. an welchen Knotenpunkten) oder ob (bzw. wo) noch Repeater verwendet werden. Auch ist nicht dargelegt, ob Router vorhanden sind. Ich gehe davon aus, dass mit »Hubs« unten Repeater gemeint sind. Zur Erklärung: »Hub« bezeichnet einen »Sternverteiler«. »Hub« bedeutet im Englischen die Nabe eines Speichenrades. Ob sich darin ein Kugellager oder ein mit Fett geschmiertes Holzlager befindet, ist mit »Hub« nicht gesagt. »Hub« sagt nicht, ob darin ein Repeater, eine Bridge, ein Switch oder ein Router enthalten ist (oder alles zusammen – bei modularen Hubs). Sämtliche Switch-Ports müssen einem Durchgangstest unterzogen werden. Dazu wird der Netzlastgenerator an einen Port des Hub in einem Segment angeschlossen.

Soweit o.k. Mit Hilfe dieser Station werden mindestens 1.000 Pakete (Abstand = 1.000 ms) mit der Minimallänge (64 Byte) an eine dem Switch unbekannte Zieladresse gesendet.

Entweder haben Sie hier irrtümlich die o.g. Werte angegeben, oder Sie würden die Messung wertlos machen. Bei einem Abstand von 1.000 ms haben wir genau eine Sekunde Abstand zwischen den Paketen. Das entspräche einer Netzlast von praktisch 0%. Nun könnte angenommen werden, dass Sie einen Abstand von 1.000 µs bezeichnen wollen, das entspräche dann einem Abstand von 1 ms. Damit ließe sich bei 10 Mbps Ethernet eine Netzlast von +/- 70 bis 90% erzeugen. Die Schwankung der Netzlast bzw. der tatsächliche Durchsatz hängt davon ab, ob der Traffic Generator allein ins Netzwerk sendet (sprich: um Mitternacht) oder bei produktivem Tagesbetrieb = Mischbetrieb, wenn auch alle Anwender ins Netz senden, und ob ausschließlich Switches oder auch Repeater (= Shared-Media-

110

Frage und Antwort: Welche Messung?

Segmente) vorhanden sind. Bei Mischbetrieb auf Shared Media (= Repeater) erlaubt das CSMA/CD dem Traffic Generator nicht, seine Sendekapazität voll zu entfalten. Weiterhin ist zu bemerken, dass eine einheitliche Verwendung der kleinsten Paketgröße von 64 Bytes die Switches zwar unter erhebliche Prozessorlast stellt, dass das Ergebnis aber eben auch nicht sehr aussagekräftig also nicht repräsentativ wäre, weil der normale Paketverkehr im Client-Server-Dialog mit wechselnden und zumeist deutlich größeren Paketen abläuft. Wenn schon, dann sollte abgestuft mit 64 Bytes, mit 512 Bytes, mit 1.024 Bytes und mit 1.518 Bytes gemessen werden. Es ist durchaus möglich, dass sich einzelne Komponenten in ihrer Latenzzeit nicht proportional zur gewählten Paketgröße verhalten, obwohl das nahe liegend wäre. Weiterhin muss zu Last- und Durchsatz- bzw. Performance-Messungen grundsätzlich Folgendes gesagt werden: Stresstests mit Paketgeneratoren sind nur behelfsweise und nur selten wirklich aussagekräftig. Es muss berücksichtigt werden, dass der tatsächliche Traffic, der den Repeater/ Switch kreuzt, eben nicht aus identischen Paketen gleicher Größe und gleichen Abstandes besteht. Vielmehr laufen Pakete wechselnder Größe bei zudem wechselnden Abständen über den Vermittlungsknoten bzw. Repeater. Zudem treffen ggf. auf allen Ports Frames ein bzw. werden auf allen Ports Frames ausgegeben. Man bräuchte also je Switch-Port einen eigenen Traffic Generator, um das auch nur annähernd simulieren zu können – was einen unrealistischen Aufwand darstellen würde. Zudem spielt die interne Switching-Engine eine herausragende Rolle. Außerdem muss gesehen werden: Verschiedene Switching-Engines reagieren unterschiedlich auf wechselnde Verkehrsszenarien: Die einen sind besser bei kleinen Paketen, die anderen besser bei großen; die einen besser bei vielen sich kreuzenden Dialogen, die anderen besser bei nur wenigen zeitgleichen Dialogen über alle Ports hinweg. Schon allein daraus ergibt sich, dass Last-Tests signifikant unterschiedliche Ergebnisse zeitigen können abhängig davon, •

ob Einzel- oder Mischbetrieb herrscht (ob also nur der Traffic Generator sendet oder auch viele andere Clients bzw. Server),

•

ob mehrere Ports unter Traffic gebraucht werden oder nur einer (Unterschied zwischen nur einem Traffic Generator oder mehreren),

•

ob gleichbleibende Datenströme generiert werden oder chaotische, wechselnde Datenströme.

Kapitel 4 • Statistik vs. Analyse

111

Weiter: Sie wollen mit dem Lasttest vermutlich Aufschluss darüber erhalten, ob Ihre vorhandene Netzwerkarchitektur bzw. das Design bzw. die vorhandenen Geräte – und das noch abhängig vom Aufbau – geeignet sind, eine bestimmte Anzahl von Anwendern bei ganz bestimmten Applikationen mit kurzen Antwortzeiten befriedigend zu bedienen. Also muss der Test darauf ausgelegt sein, Aussagen über die Tauglichkeit zu erhalten, wie sie sich aus Applikationen etc. ergibt. Hier muss nun weiter das Netzdesign grundsätzlich in Frage gestellt werden: •

Konzentrieren sich die Datenströme auf nur wenige Server, oder verteilen sie sich auf viele Server?

•

Wird mit Load Balancing gearbeitet (etwa: ATM, Cisco-VLAN) oder nur sternförmig-hierarchisch (Ethernet 802.3)?

•

Was für Server sind das? WinNT oder Unix oder NetWare?

Je nach Design – und es wurden nicht alle Fragen gestellt – stellen sich andere Anforderungen an die aktiven Netzkomponenten, sprich: an die Vermittlungsknoten. Sie sprechen zwar von NT, aber leider nur ungenau: Das Netzwerk besteht aus mehreren Servern, die über NT 4.0 verbunden sind.

Das soll entweder sagen, dass es nur WinNT-Server gibt; oder es soll sagen, dass es Server anderer Art gibt – möglicherweise Unix-Server, die von den Clients über WinNT-Server erreicht werden, die dann als sog. NFS-Gateway arbeiten. Bei wörtlichem Verständnis ist zu vermuten, dass Sie tatsächlich Unix-Server haben, die via NT-NFS-Gateways mit den Client-PCs verbunden sind. Das alles mag Ihnen wie Haarspalterei erscheinen – ist es aber nicht! Eine Messung der gewünschten Art muss schon an den Tatsachen orientiert sein, um hinreichend Aussicht auf Erfolg zu haben. Deswegen müssen wir unseren Kunden zuvor mit genauen Fragen »entlocken«, was tatsächlich das Ergebnis der Arbeit sein soll, um demzufolge die Vorgehensweise zu entwickeln. Der Empfänger muss die gesendeten Pakete aufzeichnen.

o.k. Diese Messung muss für alle Switch-Ports in beide Übertragungsrichtungen durchgeführt werden.

112

Frage und Antwort: Welche Messung?

o.k. Das Protokoll muss folgende Angaben enthalten: • Switch-Port-Nummer • Anzahl der generierten Pakete • Anzahl der auf der anderen Seite des Switches aufgezeichneten Pakete • Anzahl der Fehler und Kollisionen

o.k. Hub-Funktionstest Für diese Messung wird von einer Station aus eine Netzlast generiert und von einer anderen Station empfangen. Der Netzlastgenerator muss in der Lage sein, bis zu 95% Netzlast zu erzeugen. Die empfangende Station muss die Netzlast, die Kollisionen und die Fehler zählen und an die Adressen zu den jeweiligen Paketen eintragen. Ziel der Messung ist die Überprüfung der Funktionalität des aus der Verkabelung und den aktiven Komponenten der Schicht 1 bestehenden Gesamtsystems. Die Prüfung des Netzes beinhaltet folgende Teilschritte: • Anschluss eines Netzlastgenerators an einem Endgeräteanschlusspunkt im selben Netz. • Erzeugen von 50% Netzlast, bestehend aus Paketen mit der maximalen Länge.

Das ist nun theoretisch interessant. Oben sprachen Sie von der bei Ethernet minimalen Paketlänge (anders gesagt: Mindestpaketlänge) von 64 Bytes. Sie gingen vermutlich von der – durchaus plausiblen – Annahme aus, dass Switches bei maximal vielen Paketen auch maximal viele Prozessor- und Switching-Arbeit zu leisten hätten (Adresserkennung, Table LookUp, Port-Zuweisung, Queueing). Jetzt dürfte die Annahme bestehen, dass Repeater (die meinen Sie vermutlich mit »Hubs«) mit möglichst großen Paketen auszutesten wären, da sie keinerlei Adresserkennung betreiben. Das ist zwar nicht falsch, aber auch nicht die ganze Wahrheit. Je nach Anlage der Messung (eine oder viele Sender, gemischt oder ungemischt, s.o.) ergeben sich unterschiedliche Gesichtspunkte bei Messungen rund um Repeater. Sollte nur ein einzelner Traffic Generator arbeiten, ist die Paketgröße nahezu unbedeutend – bei Twisted-Pair nahezu vollkommen unbedeutend, bei Koax etwas weniger. Das hängt mit dem Schwingungsverhalten auf Koax zusammen unter Berücksichtigung der 64-Bit-Präambel und dem 9,6 µs langen Inter-Frame-Gap, dem Min-

Kapitel 4 • Statistik vs. Analyse

113

destabstand zwischen zwei Ethernet-Paketen seitens des Absenders; Übertragungen auf Koax-Kabeln sind eher gefährdet Verfälschungen zu erleiden, als solche auf TP-Kabeln. Je größer die Zahl der Pakete auf Koax-Kabeln je Sekunde ist, umso kleiner werden die zeitlichen Abstände und umso größer ist die Wahrscheinlichkeit, dass bei leichten Fehlern im Koax-Kabel erste Fehler auftauchen. Sollten aber mehrere Quellen senden, und das mit hoher Zugriffshäufigkeit (um nicht »Frequenz« zu sagen, was missverständlich wäre), so ist unabhängig vom Medium mit zunehmenden Kollisionen zu rechnen. Repeater aber haben bei Kollisionen ein definiertes Verhalten, das wenig Raum für Toleranz lässt und das durchaus nicht immer erbracht wird. So muss ein Repeater im Kollisionsfalle •

den unlesbaren Signalanteil eines Frames durch Stopf-Bits füllen (binär »01010101« = hex 0x55 oder »10101010"=0xAA oder Mischungen daraus);

•

außerdem stets für den vorgeschriebenen Inter Frame Gap von 9,6 µs sorgen, was bei Kollisionen keine triviale Aufgabe ist, da zwei sich überlagende Signale einen scheinbaren Ruhepegel erzeugen können, der vom Repeater als Pause zwischen zwei Paketen missverstanden werden kann;

•

unempfindlich gegenüber Überspannung sein (Pegelüberlagerungen erzeugen kleine, aber vorhersagbare Überspannungen), damit fehlerhafte Voltpegel bzw. Frequenzmuster nicht auf die anderen Ports durchschlagen; Fehlerverhalten ist hier zwar sehr selten, aber schon beobachtet worden.

Auch wenn dies wieder theoretisch erscheinen sollte: Messungen, die zu verwendbaren Aussagen bzgl. der Repeater kommen sollen, müssen ebenfalls überlegt sein. • Anschluss eines Netzanalysators an den Endgeräteanschlusspunkt mit der größten Entfernung vom Netzlast-Generator, jedoch im selben Netz.

Hiermit dürften Tests auf sog. Late Collisions gemeint sein. Diese Tests sind möglich und durchaus auch sinnvoll – sie setzen jedoch voraus, dass es sich in der vollen Ersteckung des Netzes um ein reines Repeater-LAN handelt. Sobald schon nach dem ersten Repeater-Hub ein Switch folgt, sind Late-Collision-Tests in aller Regel sinnlos, da die physikalisch-logischen Voraussetzungen für Late Collisions gar nicht vorliegen. Late Collisions ergeben sich dann, wenn ein Multiple Access in der Art erfolgt, dass ein zweiter Adapter zu senden beginnt, nachdem ein anderes Signal bereits mit einer erreichten Laufzeit von größer/gleich 25,6 µs (= 32 Byte Times) unterwegs ist, aber nicht per Carrier Sense vom zweiten Adapter erkannt werden kann, da dieser in einem Kabelabschnitt angeschlossen ist, das außerhalb der Reichweite der o.g. 25,6 µs liegt, gesehen ab Sendeposition des ersten Adapters. Man spricht dann von Segmentüberlänge bzw. Laufzeitüberschreitung.

114

Frage und Antwort: Welche Messung?

Dies war früher bei Koax-Verkabelungen bald schon regelmäßig gegeben (und natürlich fehlerhaft); bei der heutigen strukturierten Gebäudeverkabelung jedoch sowie dem Einsatz von Switches ist kaum anzunehmen, dass bei Twisted-PairKabeln die der maximalen Signallaufzeit von 25,6 µs entsprechende maximale Segmentlänge von ca. 925 m unter Einschluss von bis zu vier Repeatern überschritten wird (alles bezogen auf 10 Mbps Ethernet). Ich will nicht ausschließen, dass Sie die Angaben aus einer Ihnen vorliegenden Literatur übernommen haben. Möglicherweise handelt es sich um ein Buch aus der Anfangszeit von Ethernet oder eine sonstige, ältere Quelle. • Aufzeichnung der Daten für zehn Minuten und mit der statistischen Analyse der Daten.

Das ergibt nur dann Sinn, wenn bei Mischbetrieb gemessen wird (Analyzer sendet während des normalen Tagesbetriebs). Das Messprotokoll muss folgende Angaben beinhalten: • Bezeichnung des Netzes • gemessene Netzlast • Anzahl der Fehler und Kollisionen

o.k. Bitte erstellen Sie schnellstmöglich ein Angebot für Ihre Dienstleistung und teilen Sie uns mit, wann sie den nächsten Termin für eine Überprüfung frei haben. Uns wäre ein Termin noch in diesem Jahr wichtig. Gruß aus F. Steffen K.

Termine sind mit Frau Jonas abzustimmen – sie ist unser Master of Time. Dringlich jedoch ist, dass Sie uns folgende Dokumentationen zur Verfügung stellen: •

Lageplan/Topographie (= räumliche Anordnung)/Topologie (Zugriffsverfahren je Segment)

•

Wo stehen welche Server mit welchen Daten bzw. welchen Applikationen?

•

Wie viele Anwender greifen mit welchen Applikationen auf welche Server zu?

Zudem:

Kapitel 4 • Statistik vs. Analyse

115

•

Was haben Sie demnächst vor? Wie wollen Sie umbauen? Wohin wollen Sie migrieren?

•

Welchen Anforderungen muss das Netz demnächst genügen?

•

Was soll der Test eigentlich zu Tage fördern?

Mal so gesagt: Das ist alles zu machen. Aber ein Plan muss schon sein. Wir wollen ja nicht in irgendeine Falle laufen. In Abwandlung des berühmten ChurchillZitates gilt: Jede Statistik ist nur so gut wie die persönliche Fälschung ... Will sagen: Die Tests sind nur so gut wie die Berücksichtigung ihrer Bezugsgrößen und Kontrollgruppen – wobei, zugegeben, Doppel-Blind-Messungen zur Sicherung der statistischen Unantastbarkeit den Rahmen des Vertretbaren sprengen würden! Mit freundlichen Grüßen, Frank R. Walther Synapse: Networks

4.2

Zweiter Anlauf Nachfrage des Kunden: Sehr geehrter Herr Walther, wir sind sehr angenehm überrascht von Ihrem Engagement und Ihrer Kompetenz. Folgende Netzwerkausstattung liegt zugrunde: • Topologie Ethernet 100 Mbit • Ein Hauptswitch: 3Com Superstack II 3300 24-port Switch • Zwei Hubs: 3Com Superstack II 500 dualspeed Hub (2 x 12-Port, 1x 24-Port) • An diesen Hub sind nochmal zwei Untersegmente 12-port-D-Link-Hubs angeschlossen • 3Com 3C905TX-B Netzwerkkarten Als Server werden IBM PC-Server 330 mit folgender Konfiguration eingesetzt: • 2 x Einrichtung unter Windows NT 4.0 (1 x PDC, 1 x BDC) • 2 x Einrichtung unter SCO Unix (auf jedem Rechner läuft eine Branchenlösung) Das netzwerkweite Protokoll ist TCP/IP. Die Arbeitsstationen greifen auf die Unix-Server über TCP/IP direkt zu, lediglich für eine Branchenapplikation ist ein Extra-Client installiert, der aber auch auf das TCP/IP-Protokoll zugreift. Zusätzlich sind einige Printserver von Intel im Einsatz. Es handelt sich im Netz um ca. 60 aktive Anschlüsse. Es wird neben dem Branchenprogramm noch mit MS-Office-Programmen gearbeitet, die ihre Daten auf den NT-Servern ablegen; die Programme selbst sind auf den Arbeitsstationen lokal installiert.

116

Zweiter Anlauf

Da das Netzwerk zur Zeit lt. Kundenangaben nur zu 30% Prozent genutzt wird, weil die Unix-Anwendungen erst ab dem 01.01.1999 in Betrieb gehen, möchte der Kunde sichergehen, dass das Netzwerk nicht zusammenbricht bzw. schlechte Performance an den Tag legt. Die Netzwerkkonzeption war aber ausschließlich Vorgabe des Kunden. Bitte informieren Sie uns kurzfristig, mit welchem Kosten- und Zeitaufwand wir für den Test rechnen müssen. Gruß aus F. Steffen K.

Unsere Antwort: Sehr geehrter Herr K., schon sieht das nämlich alles ganz anders aus. 1. »Das Netz« – was ist das? Der Kunde versteht darunter meistens: Kabel, Stecker, Buchsen, Repeater, Bridges, Switches. Dummerweise werden oft die Client-PCs und Server schon nicht mit hinzugezählt. Und schon gar nicht wird dazu gezählt: das Arbeitsverhalten vom Anwender (= Mensch), Anwendung (= Applikation), Client-PC (Betriebssystem, Treiber, etc.) und Server (Betriebssystem, Treiber, Daemons, etc.). 2. Leistungsschwachstellen Es ist ein berechtigtes Interesse des Kunden, »das Netz« auf seine Leistungsfähigkeit hin zu untersuchen. Der Kunde hat aber meistens – so auch hier – reichlich naive Vorstellungen davon, welche Umstände dazu führen können, dass »das Netz« am Ende »den Anforderungen nicht gewachsen« ist. Wir dröseln das also mal auf: – 2.a – Leitungsdurchsatz 10 Mbps, 100 Mbps, 1.000 Mbps – hier gibt es erkennbare Zusammenhänge zwischen Datenaufkommen und Verzögerung, wenn der Leitungsdurchsatz nicht ausreicht. Bremse Nr. 1 also ist ggf. der Stau am Ausgangsport beliebiger Teilnehmer (PCs, Bridges, Switches, Router), wenn die Leitung nicht schnell genug alle Daten aufnehmen kann. – 2.b – Vermittlungslatenz Die Verarbeitungszeit in Bridge/Switch/Router ergibt eine weitere Latenzzeit bzw. Verzögerung. Dies geschieht völlig unabhängig von der Leitungsgeschwindigkeit.

Kapitel 4 • Statistik vs. Analyse

117

Wie ich in der vorangegangenen Mail schon schrieb, ist die Architektur des Netzknotens u.a. dafür verantwortlich, mit welchen Latenzzeiten zu rechnen ist. So wurde mit FibreChannel bzw. jetzt Gigabit-Ethernet eine Hardware-Architektur eingeführt, die den vorigen Switch-Generationen dramatisch überlegen ist. Bremse Nr. 2 sind also ggf. Vermittlungsknoten. – 2.c – Client-PCs Auch der Client-PC kann dafür verantworlich sein, dass die Arbeit nur langsam vorangeht. Der Kunde sagt dann immer sofort: »das Netz« sei schuld daran. Das ist oft schlicht nicht richtig. Also: Bremse Nr. 3 kann der Arbeitsplatz-PC sein. – 2.d – Server In den meisten Fällen ergibt sich bei Messungen, dass nicht »das Netz« insgesamt die beanstandeten Verzögerungen verursacht, sondern dass es die Server sind, die schlicht nicht schnell genug antworten können. Latenzzeit ergibt sich hierbei also durch zu lange Antwortzeit. Also: Bremse Nr. 4 sind gerne die Server (und eher WinNT, weniger NetWare oder Unix, wenn nur auf einem Prozessor gearbeitet wird). – 2.e Massenspeicher Die Art, in welcher die Massenspeicher angeschlossen und an »das Netz« geschaltet sind, spielt ebenfalls eine Rolle. Typischerweise sind Daten heute – noch – das »Eigentum« jeweils nur eines Servers. Das beginnt sich dank Fibre Channel bzw. SCSI-3 jetzt zu ändern: Mehrere Server teilen sich einen gemeinsamen Plattenturm und »sehen« die Gesamtheit aller Daten als »ihre« eigenen Daten. Dadurch kann man im Netzwerk selber (z.B. mit ATM) ein Load Balancing einrichten mit dem Ziel, dass die vor dem Plattenturm stehenden Server gleichmäßig mit AnwenderRequests bzw. ganz allgemein gleichmäßig mit I/O-Aufgaben ausgelastet werden können. Genau das ist nämlich heute meistens noch anders: Einige Server stöhnen unter der Last, während andere nichts zu tun haben. Bei Ihrem Kunden ist dieses Argument vielleicht weniger anwendbar, da er nur vier Server hat. Und dennoch: Bremse Nr. 5 kann eine mangelhafte Schnittstelle sein, mit der Massenspeicher »dem Netz« gegenüber verfügbar gemacht werden, wobei mit »Schnittstellen« hier schlicht Server gemeint sind, dessen Zweck es ist, (a) Caching vorzuhalten und (b) Berechtigungen zu führen (die Funktion des File and Record Locking liegt dann auf dem Plattenturm).

118

Zweiter Anlauf

3. Aussagekraft einer Messung Der Kunde will wissen, ob er mit nennenswerten Verzögerungen bzw. Antwortzeiten zu rechnen hat, wenn die neuen Applikationen in Betrieb genommen werden. Nicht zu empfehlen wäre z.B. ein simpler »Stresstest« mit Traffic Generator: Wir müssen die verschiedenen Applikationen bei ihrer Arbeit beobachten: – Wie viele Dateien werden je Anwender je Arbeitsgang/je Programm-Modul geladen? – Wie groß sind diese Dateien? – Über welche (lange oder kurze) Zeit hinweg erstreckt sich der Dateizugriff? – Wie haben die Programmierer das jeweils gelöst? Um ein Beispiel zu nennen: Im September 1998 rief mich eine Bundesstiftung an. Man hatte eine neue Datenbank-Software eingeführt und die Mitarbeiter wurden just darauf geschult. Dann erging der Notruf an uns: Das Abspeichern eines einzelnen Datensatzes koste 5-10 Minuten, und das bei zehn Teilnehmern im Kurs, und ganz bestimmt reichten die 10 Mbps im Ethernet nicht aus, oder das Koax-Kabel sei defekt, oder feindliche Marsmännchen haben die Bits geklaut. Ich stellte fest, dass der Fehler in diesem Fall in der SQL-Anwendung lag. Wenn aus der Menge von mehreren 100.000 Datensätzen einige herausgeholt werden sollten (sagen wir: die Datensätze aller Menschen, deren Name mit »A« anfängt), geschah Folgendes: Anstatt an den Client-PC nur so viele Datensätze zu senden, wie just in dessen Sichtfenster passte (nur ein Datensatz bei Einzeldarstellung, ca. 20 Datensätze bei Listendarstellung), sowie die Zahl der Hits/Treffer, schickte der SQL-Server alle Datensätze zum Client-PC – auch auf die Gefahr hin, dass dann 100.000 Datensätze über die Leitung gingen, obwohl der Anwender vielleicht nur Bruchteile davon brauchte. Damit aber nicht genug: Änderte der Teilnehmer nunmehr nur einen Datensatz und drückte auf »Speichern«, so wurden alle (in unserem Beispiel: 100.000!) Datensätze zurückgeschickt an den SQL-Server. Dieser nun verglich alle Datensätze darauf, ob sie geändert worden waren. Entdeckte er nun den geänderten Datensatz, fragte er den Client, bei dem nun ein entsprechendes Popup-Fenster auf den Monitor kam: »Wollen Sie die Änderungen wirk-

Kapitel 4 • Statistik vs. Analyse

119

lich speichern?« Drückte der Anwender dann auf »Ja«, gingen die Datensätze erneut sämtlich über die Leitung! Die Anwendung hätte das Problem so lösen müssen: Das Front-End-Modul im Client-PC erkennt bereits, dass eine Änderung erfolgte (die Information liegt ja vor, wenn editiert wird), und fragt selbstständig, ob »wirklich gespeichert werden« soll; falls dann »ja« geantwortet wird, geht dann nur der eine, geänderte Datensatz zurück an den SQL-Server. So wäre das alles kein Problem gewesen. Und um die Antwortzeiten vollends explodieren zu lassen, haben die Programmierer sich das Gimmick einfallen lassen, sämtliche Datensätze – in jede Richtung, also hin wie zurück – zweimal über die Leitung zu schicken, nämlich erstens in Großschreibung und zweitens in Kleinschreibung. Sicher ist sicher! Verstehen Sie mein Beispiel? Was nutzt eine Messung, die »das Netz« austestet, wenn die anderen Vorgänge nicht gesehen werden, die an der späteren, tatsächlichen Arbeit der Anwender beteiligt sind? Noch ein kleines Beispiel: Ich habe mehrfach – in den letzten Wochen übrigens bei zwei Kunden massiv – Routing-Fehler diagnostiziert, und zwar der Art, dass Daten auf demselben LAN-Segment mehrfach zwischen Routern hin- und her pendeln, weil das Routing bei den Anwendertreibern (teilweise) sowie bei den Routern selber (total) falsch eingestellt war. Folge: Jedes Datenpaket war zweimal auf der Leitung. Das erhöht – so mal ganz nebenbei – »die Netzlast« um den Faktor 100 Prozent. Solche Fehler können Sie mit simplen Lasttests, wie sie Ihr Kunde fordert, niemals heraus finden. Ihr Kunde denkt so wie die meisten: Er denkt, ein Verkehrssystem müsse daraufhin untersucht werden, ob die Straße denn Schlaglöcher hätte oder ob Tellerminen versteckt wären. Was soll das? Das eine ist einigermaßen unwahrscheinlich, das andere vollkommen unsinnig. Wenn ich ein Verkehrssystem untersuche, dann frage ich: – Wo gibt es Einbahnstraßen – und: sind die sinnvoll? – Wie viele Spuren hat die Autobahn? – Wer will wann warum in die Innenstadt, und von wo kommt er, und hätte er andere Einkaufs-Center zur Verfügung? – Würde er draußen an der Peripherie einkaufen, wenn es dort Entlastungsangebote gäbe, oder muss er zwingend in die City?

120

Zweiter Anlauf

– Gibt es Verkehrsleitsysteme, welche die Staus anzeigen und die Kapazität der Parkhäuser? – Wären Umgehungsstraßen sinnvoll oder eine Untertunnelung der Innenstadt? – Welche Maßnahmen wären geeignet, den Verkehr erst gar nicht entstehen zu lassen, indem die Leute auf öffentlichen Nahverkehr umsteigen? – Warum tun sie das aber nicht, sondern fahren weiter im Auto und erzeugen so den Stau selber mit, über den sie schimpfen? Die Logik eines Verkehrssystems ist genauso wichtig wie die Hardware, also wie das Trägersystem. Und: Motivation und Verhalten derer, die es benutzen, führen erst zu der Bewertung des Systems! Wenn überall nur Busse fahren, sagen alle: »Schöne Straßen, alles gut!« Wenn aber alle selber mit dem Auto fahren, sagen sie: »Mist-Straßen, viel zu eng.« Deswegen führen ja immer mehr NT-Anwender Terminal-Lösungen ein, bei denen zum Client-PC nur noch die VGA-Daten ausgegeben werden. Das entlastet »das Netz« fast vollständig, da keine Nutz- und Applikationsdaten mehr über die Leitung gehen. 4. Was der Kunde vermutlich wünscht Er will wissen, ob bei Normalbetrieb die Antwortzeiten klein sein werden. Das kann man letzten Endes nur testen, wenn alle Anwender da sind und alle Applikationen genutzt werden – wenn also an einem ganz normalen, repräsentativen Tag gemessen wird. Ich schlage also vor: – 4.a – Erste Messung Wir kommen an einem Tag im Dezember, um »dumme Statistik« zu betreiben und um vielleicht mal testweise die neuen Server zu benutzen, um zu beobachten, wie die Applikationen arbeiten. Dies tun wir rein vorsorglich, um zu vermeiden, dass es einen groben Fehler gibt, der nicht ins neue Jahr übernommen werden muss. – 4.b – Zweite Messung Wir kommen im Januar (besser: Februar) noch einmal wieder, wenn die Applikationen von den Anwendern auch flächendeckend verwendet werden, um dann das Verkehrsszenario aufzuschlüsseln, zu dokumentieren und zu bewerten. Eigentlich kommt es nur auf Schritt 4.b an – aber ich vermute, dass Ihr Kunde sehr nervös wäre, wenn Schritt 4.a nicht erfolgen würde.

Kapitel 4 • Statistik vs. Analyse

121

Ich sage es mal so: Ich verdiene ja gerne das Geld. Aber im Dezember kann ich auch einen Tag mehr am Schreibtisch gut gebrauchen. Ich bin also unentschlossen. Und somit überlassen wir es Ihrem Kunden, ob ich im Dezember noch komme. Viel wichtiger ist die Messung unter Normalbedingungen, weil sich nur dann wirklich aussagekräftige Bewertungen vornehmen lassen. Es liegt nun in Ihrer Hand! Bis dahin: Alles Gute, Frank R. Walther Synapse: Networks

4.3

Dritter Anlauf und letzte Klärung Sehr geehrter Herr K., Sie fragen nach dem Unterschied zwischen Lasttest und Statistikmessung. Nun, sagen wir es mal ganz platt: 1. Lasttest Der Lasttest spielt sich auf dem Physical Layer (L1) ab und soll die Frage beantworten, ob die Physik (Kabel, Repeater, Bridges, Switches) fehlerfrei und schnell genug arbeiten. Über irgendeine Form der Logik wird hier entweder gar nicht oder doch nur mäßig gesprochen. 2. Statistikmessung Die Statistikmessung spielt sich auf dem Data Link Layer (L2) ab und fragt: Wer ... – ... sendet bzw. empfängt ... – ... mit welcher Gegenstelle ... – ... wie viele Pakete/Bytes ... – ... bei wie viel Fehlern ... – ... über welche Wege ... – ... und aus welchem Anlass? Man sagt hierzu auch oft: Verkehrsmessung bzw. Verkehrsstatistik bzw. das Erzeugen einer Verkehrsmatrix.

122

Das Ergebnis

Eine dumme Lastmessung halte ich – von wenigen Ausnahmen vielleicht mal abgesehen – für schlicht unsinnig, weil – wie schon in früheren Mails beschrieben – der Wert dieser Tests bzw. der Wert der Aussagen, die man daraus gewinnen kann, praktisch gleich Null ist. Das, was die Kunden für gewöhnlich interessiert, sind diese Fragen: •

Ist mein Netz physikalisch sauber? Gehen auch keine Pakete verloren?

•

Bietet mein Netz kurze Antwortzeiten für den Anwender?

•

Welche Verzögerungszeiten (= Verlängerungen der Antwortzeiten) fallen auf Server, Client, Switch, Router?

•

Arbeiten meine Applikationen sauber oder verursachen sie Fehler und/oder Verzögerungen?

Zum letzten Punkt: Gerade gestern habe ich bei einem Kunden gesehen, wie Lotus-Notes es fertig bringt, bei einem Request auf z.B. 1.500 Byte Daten mit Paketen zu antworten, in denen wechselnd 2 bzw. 4 Byte Daten drin sind. Dass dann 300-400 Pakete unterwegs sind, wo eines gereicht hätte, ist logisch gesehen eine Katastrophe, die Netzlast geht dramatisch hoch und die Anwender sagen (wenn viele gleichzeitig auf Lotus-Notes zugreifen) »das Netz ist langsam«, obwohl »das Netz« völlig korrekt arbeitet. »Lasttest« heißt in letzter Konsequenz: Wir sperren am Sonntag die Autobahn und gucken mal, ob ein Super-Doppel-Turbo-Hyperaum-Porsche da auch mit 1.373.374 km/h drüber brausen kann. Kann er das, ist die Autobahn »schnell«. Kann er das nicht, ist die Autobahn eben »langsam«. Der Unsinn einer solchen Versuchsanordnung tritt offen zu Tage – weswegen wir auch davon in aller Regel abraten. Mit freundlichen Grüßen Frank R. Walther Synapse: Networks

4.4

Das Ergebnis

4.4.1

Statistik vs. Analyse Es soll noch erwähnt werden, dass die gewünschte Messung nicht zustande kam. Am Ende hatte der Kunde eingesehen, dass er sich von der gedachten »Lastmessung« etwas versprochen hatte, was sie niemals hätte leisten können. Statistik kann Analyse nicht ersetzen – und umgekehrt. Wann was geeignet bzw. angemessen ist, muss von Fall zu Fall jeweils neu entschieden werden.

Kapitel 4 • Statistik vs. Analyse

123

Und doch liegt der Schwerpunkt eindeutig auf dem analytischen Teil, nicht auf der Statistik:

4.4.2

»Das Netzwerk ist zu langsam« Häufig heißt es, wenn ein Vorgang zu lange dauert: »Das Netz ist zu langsam«. Was bedeutet das? Erfahrungsgemäß liegen Probleme im Netzwerk in den seltensten Fällen in Repeatern oder Switches begründet (eher schon in Routern) – genau die aber werden mit dieser Aussage hauptsächlich in Verdacht genommen. Meistens sind Probleme wie Verzögerungen, überlange Antwortzeiten oder Protokollfehler in den Endgeräten zu suchen, also Servern, Hosts, Großrechner-Gateways einerseits und Arbeitsrechnern, Clients, Terminal-Emulationsrechnern andererseits. Auch Routing-Fehler sind eher selten durch die Router selber veranlasst; meistens sind falsche Konfigurationen an den Endgeräten hierfür verantwortlich (allein oder doch überwiegend). Verzögerungen Die meisten Verzögerungen ergeben sich aus folgenden Umständen: •

überlastete Server (eher WinNT, weniger NetWare oder Unix)

•

falsch arbeitende Kommunikationstreiber (Fehler in TCP/IP, NetBIOS IPX/ NCP etc.)

•

falsch arbeitende Applikationen

•

falsche Konfigurationen, z.B. im IP-Bereich (falsches Routing etc.)

Viele LAN-Administratoren haben keinen hinreichenden Eindruck davon, welche teilweise aberwitzigen Fehler in ihrem Netzwerk tagtäglich gegeben sind. Beispiel 1 Es kann vorkommen, dass rund 30 bis 50% der Datenlast auf dem Backbone überflüssig (künstlich erzeugt) sind durch Fehler in der Konfiguration von NTServern bzw. durch Routing-Fehler; diese Fehler sind teilweise nur extrem schwer bzw. nur unter großem Aufwand vermeidbar. Beispiel 2 Es kann vorkommen, dass bis zu 50% der Datenlast auf dem Backbone überflüssig (künstlich erzeugt) sind durch falsche Protokollkonfigurationen an NetWareServern; dies kommt gelegentlich vor, wenn verschiedenen NetWare-Versionen der verschiedenen fünf bis zehn Jahre parallel laufen.

124

Das Ergebnis

Beispiel 3 Es kann vorkommen, dass ein Client eine Datei vom Server im Umfang von sagen wir- 1.000 Byte nicht mit einer einzigen Abfrage anfordert (was normal wäre), sondern in 1.000 Abfragen je Nutzlast von je 1 Datei-Byte. Oder der Client fordert die Daten auf einmal an, aber der Server gibt sie nur in diesen Kleinstmengen heraus. Steigerung der Netzlast: mehrere Hundert Prozent. Beispiel 4 Es kann vorkommen, dass Clients Dateien vom Server nicht einmal je Anlass abfragen, sondern mehrfach hintereinander. Es wurde schon der Fall beobachtet, bei dem WinNT-CAD-Workstations Dateien von bis zu 100 MByte Größe bis zu 30-mal vom Server anforderten (Bildschirm: leer), bis endlich nach dem letzten Mal die Datei auf dem Bildschirm ausgegeben wurde. Ladezeit: Teilweise bis zu 15 Minuten und mehr !!

4.4.3

Fazit: Wechselspiel von Statistik und Analyse Es sollte deutlich geworden sein, dass »dumme Statistik« zwar oft, aber nicht immer helfen kann. Der Kauf eines zu sehr auf Statistik beschränkten Analyzers kann schnell in erzwungener Blindheit des Analysten enden, der Fehler der geschilderten Art nicht mehr erkennen kann. Im Kapitel 3 »Grundlagen der Methodik« wurde ausführlich auf das Wechselspiel von Statistik und Analyse hingewiesen. So gut Analyzer auch sein mögen: Es ist unmöglich, Millionen und Abermillionen von LAN-Frames zu sichten und ohne irgendeinen Hinweis den Fehler schnell zu finden. Es ist unbedingt sinnvoll, den Ort des Fehlers sowohl räumlich (Client, Server, Backbone) sowie logisch (Netzwerkschicht) einzugrenzen. Dies kann oft schnell und zuverlässig durch die richtige Deutung von Statistiken in Form von Verkehrstabellen geschehen. Sind die Hinweise gut, die hieraus gewonnen wurden, setzt die gezielte Datenaufnahme mit der entsprechenden Analyse ein. Im Ergebnis bedeutet dies also: •

Am Anfang steht oft die Statistik.

•

Am Ende steht oft die Analyse.

Für beides braucht man die nötige technische Ausstattung, und die ist für jeden Anwendungsfall verschieden.

Kapitel 5 Switches und Mirror Ports 5.1 5.2 5.3 5.4 5.5 5.6 5.7

Messungen in Shared Media LANs Messungen in Switched LANs Half-Duplex Ports Full-Duplex Ports Messung auf der Seite der Endgeräte Eingriff ins System: Gefährlich! Messungen am Switch: Media Tap!

126 126 127 129 131 132 133

126

Messungen in Shared Media LANs

Messungen sind immer nur so gut •

wie die eingesetzte Messtechnik und

•

wie der gewählte Messpunkt.

Nirgends wird das deutlicher als bei Messungen am Switch.

5.1

Messungen in Shared Media LANs In Shared Media LANs reicht es, den Analyzer irgendwo ans Kabel bzw. ans Medium zu hängen: •

an das T-Stück eines Koax-Kabels

•

an einen Ringleiterverteiler

•

an die EAD-Dose eines Koax-Kabels

•

an den Port eines Repeaters (als Twistd-Pair-Repeater auch »hub« genannt)

Jeder dieser Messpunkte reicht, um alle durchs LAN laufenden Frames zu sehen.

5.2

Messungen in Switched LANs Während Messungen in Shared Media LANs also technisch wenig anspruchsvoll sind, sind Messungen in einem Switched Network deutlich schwieriger. Hier reicht es nicht, den Analyzer an einen beliebigen Verteiler-Port zu klemmen – denn bei einem Switch bekäme der Analyzer nichts weiter zu sehen als die Broadcasts und Multicasts. Alle Datendialoge zwischen jeweils zwei Endgeräten (Client/Server, Host/Terminal) gingen am Analyzer vorbei. Sofern nicht am Switch wiederum ein Shared Media LAN angeschlossen ist, an das wiederum der Analyzer sinnvoll messen kann, muss das Messgerät am sog. Mirror Port angeschlossen werden, oder es muss außerhalb des Switches ein Messpunkt geschaffen werden •

durch das Zwischenschalten eines Repeaters (Ethernet) oder Ringleitungsverteilers (Token-Ring) oder

•

durch das Zwischenschalten eines sog. Media Taps oder Media Splitters.

Das alles will gut überlegt sein. Es geht dabei grundsätzlich um das Problem jeder empirischen Wissenschaft: Beim Eingriff ins beobachtete System wird die Beobachtung schnell wertlos. Wenn das Zuschalten des Messgerätes also einen Eingriff ins zu messende System darstellt, ergibt die Messung keinen Sinn mehr.

Kapitel 5 • Switches und Mirror Ports

127

Abb. 5.1: Das Prinzip des Media Taps (hier: Century Tap/Shomiti)

Es ist im Prinzip dabei gleichgültig, ob wir über TokenSwitching oder EtherSwitching bzw. Fast Ethernet Switching oder Gigabit Ethernet Switching sprechen. Wir reden also über die Kunst, den Messpunkt richtig zu definieren bzw. zu setzen.

5.3

Half-Duplex Ports Arbeiten die Switch-Ports nur im Halbduplex-Modus (Senden und Empfangen abwechselnd auf denselben Adern), so gibt es zwei Möglichkeiten der Messung:

5.3.1

Mirror Port Der Analyzer wird am Mirror Port des Switches angeschlossen, und der Datenstrom eines anderen Ports wird am Mirror Port gespiegelt ausgegeben. Messungen am Mirror Port haben jedoch gravierende Nachteile! Im Kern handelt es sich um folgende Punkte: •

Der Switch wird beeinträchtigt. – Die Prozessorleistung wird gegenüber dem LAN-Traffic vermindert, da die zusätzliche Aufgabe des Mirrorings zu erledigen ist. – Die Speicherbelegung verändert sich zugunsten des Mirror Ports und zuungunsten der normalen Switch-Ports.

•

Der Switch gibt nicht alle Daten aus. – Es werden keine defekten Frames ausgegeben – Es werden keine VLAN-Protokolle ausgegeben

128

Half-Duplex Ports

Eine Messung am Mirror Port ist im Grunde nur dann zulässig, wenn von vornherein klar ist, dass der Switch absolut »sauber« ist, also nicht selber Fehler erzeugt oder auf Fehler in den Datenpaketen reagiert, wenn also der Switch nicht selber Teil des zu findenden Fehlers ist. Sonst nämlich besteht die Möglichkeit, dass die Messung am Mirror Port des Switches nicht die ganze Wahlheit zeigt! Die vermeintliche Gewissheit aber, dass der Switch nicht Teil des Problems ist, kann sich auf kaum mehr stützen als reine Vermutung. Schon allein der Umstand, dass Switches am Mirror Port weder defekte Frames anzeigen (weil diese schon am Eingang des zu spiegelnden Switch-Ports verworfen werden), noch VLAN-Protokolle ausgeben, macht Messungen am Mirror Port schnell wertlos (je nach Fehlerszenario). Außerdem muss berücksichtigt werden, dass der Mirror-Betrieb den Switch Prozessorleistung kostet sowie zusätzlichen Speicherbedarf erzeugt, der im schlechtesten Falle den zu messenden LAN-Traffic beeinträchtigt bzw. verändert. Eine Messung ist aber nur dann »sauber«, wenn sie so weit »draußen« abläuft wie nur irgend möglich. Sobald das zu messende System durch Eingriffe verändert wird, sobald also das Messgerät selber Teil des Systems wird und dessen Arbeitsweise dadurch verändert bzw. beeinflusst wird, ist die Messung nach strengsten Kriterien schon unbrauchbar. Wozu aber wird denn ein Analyzer eingesetzt, wenn nicht zu dem Zweck, ein möglichst genaues Abbild der Datenströme zu erhalten? Zum Mirror Port gibt es zwei Alternativen (je nach Topologie und Bitrate):

5.3.2

•

das Zwischenschalten eines Repeaters bzw. Ringleitungsverteilers

•

das Zwischenschalten eines professionellen Media Taps

Repeater/RLV Zwischen den Switch-Port und das zu messende Endgerät (Client, Server, Sonstiges) wird ein Repeater (10/100 Mbps Ethernet) oder ein Ringleitungsverteiler (4/16 Mbps Token-Ring) geschaltet. Während der Datenverkehr des Endgerätes immer noch über denselben SwitchPort läuft, aber eben auch den dazwischengeschalteten Verteiler durchläuft, kann nun der Analyzer am Repeater angeschlossen werden. Faktisch ersetzt der Repeater (bzw. RLV) den Mirror Port. Diese Lösung hat einen ganz extremen Vorteil gegenüber einer Messung am Mirror Port: Die oben beschriebenen Nachteile einer Messung am Mirror Port entfallen. Dennoch gibt es noch eine Alternative zum Repeater bzw. RLV, und zwar das professionelle Werkzeug des Media Tap:

Kapitel 5 • Switches und Mirror Ports

5.3.3

129

Media Taps/Media Splitter Media Taps sind kleine Boxen, die zwischen den Mirror Port und das zu beobachtende Endgerät geschaltet werden; zusätzlich zum Switch-Port und dem Endgerät wird als Drittes der Analyzer am Media Tap angeschaltet. Ansonsten sei auf die Ausführungen im Abschnitt 5.4.2 verwiesen.

5.4

Full-Duplex Ports Voll-Duplex-Anschlüsse (Senden und Empfangen gleichzeitig über verschiedene Adern) können nicht über den Mirror Port gemessen werden, da ihr Gesamtdurchsatz 200 Mbps (Tx/Rx) erreichen kann, während beim Analyzer (in welcher der folgenden Konfigurationen auch immer) nur 100 Mbps über einen Adapter aufgenommen werden können. Liegt also Full-Duplex-Mode vor, gibt es nur noch zwei Möglichkeiten.

5.4.1

Rücksetzung auf Half-Duplex Der Switch-Port wird auf Half-Duplex zurückgeschaltet. Ansonsten wird verfahren, wie im obigen Abschnitt 5.3 geschildert wurde (Mirror Port, Repeater, Ringleitungsverteiler). Der Datenstrom verläuft bei Switches immer nur von (Eingangs-)Port zu (Ausgangs-)Port; ein an einem dritten Port (= Mirror Port) angeschlossener Analyzer »sieht« dabei nichts. Um die Messung zu ermöglichen, wird daher der Datenstrom, der über einen bestimmten Port läuft, auf den Mirror Port gespiegelt. Hierbei verhält sich der Analyzer rein passiv. Dies erfordert jedoch, dass der Server-Port nur auf halb-duplex konfiguriert ist: Da der Mirror Port in jedem Falle nur mit 100 Mbps senden bzw. der Analyzer nur mit 100 Mbps empfangen kann, darf niemals am Server-Port eine Datenmenge größer 100 Mbps entstehen; hierzu muss der Server-Port auf halb-duplex eingestellt sein. Das alles ist unbefriedigend. Werden Full-Duplex-Ports auf half-duplex heruntergestuft, stellt dies einen Eingriff dar, der das ursprüngliche, zu messende System verändert. Dies ist grundsätzlich problematisch. •

Die Arbeitsweise der Switches wird stark verändert (siehe Punkt 5.3.1 ).

•

Die Arbeitsweise der Endgeräte, insbesondere Server, wird stark verändert, da während der Messung der Server nicht mehr maximal 200 Mbps Tx/Rx zu bewältigen hat, sondern nur noch maximal 100 Mbps Tx/Rx.

Ist gleichwohl keine andere Möglichkeit als die Herabstufung von voll-duplex auf halb-duplex gegeben (mangels Media Tap beispielsweise), so kann man sich nur noch wie folgt helfen:

130

Full-Duplex Ports

•

Tritt der Fehler nach der Herabstufung des Switch-Ports auf half-duplex immer noch auf, beweist dies sofort die Belanglosigkeit des Eingriffs, und die Messung kann erfolgreich durchgeführt werden.

•

Tritt der Fehler nach der Umstellung nicht mehr auf, zeigt dies sofort, wo der Fehler zu suchen ist: – Entweder haben Switch-Port oder LAN-Adapter beim Full-Duplex-Betrieb technische Probleme (dann hilft der Austausch), – oder das angeschlossene Endgerät war mit dem Full-Duplex-Betrieb überfordert.

Allerdings verhilft diese Form der Diagnose nicht zur genauen Beschreibung des Fehlerhergangs, da nur ein indirekter Rückschluss möglich ist. Die Umstellung von full-duplex auf half-duplex führt also zu erheblichen und unerwünschten Einschränkungen; darum ist ein Media Tap die bessere Lösung.

5.4.2

Media Taps/Media Splitter Media Taps sind kleine Boxen, die zwischen den Mirror Port und das zu beobachtende Endgerät geschaltet werden; zusätzlich zum Switch-Port und dem Endgerät wird als Drittes der Analyzer am Media Tap angeschaltet. Media Taps haben unter allen Umständen (half-duplex, full-duplex, Kupfer, Fiber) folgende Vorteile: •

Auf den Switch wird in keiner Weise eingewirkt; seine Arbeitsweise, sein Verhalten werden nicht verändert; hierdurch erlangt die Messung überhaupt erst die Qualität, Ergebnisse zu bringen, die unangreifbar sind.

•

Der Switch wird nicht durch die Operation des Mirror-Betriebs in seiner Prozessorleistung geschwächt.

•

Während ein Switch zwischen LAN-Port und Mirror Port fehlerhafte Frames unterdrückt und die Messung dadurch nur noch eingeschränkt gültig sein kann, macht der Media Tap alles sichtbar.

•

Während Switches am Mirror Port keine VLAN-Information ausgeben, sind die VLAN-Protokolle über den Media Tap sehr wohl sichtbar.

•

Spezielle Media Taps wie der »Century 12 Tap« (Shomiti, USA) erlauben die simultane Überwachung von bis zu zwölf Full-Duplex Switch-Ports.

Der Einsatz von Media Taps bzw. Media Splittern ist jeder anderen Messtechnik am Switch deutlich überlegen.

Kapitel 5 • Switches und Mirror Ports

131

Das Geld, das in diesen Modulen angelegt wird, macht sich im Laufe der Zeit mehr als bezahlt. Schon allein der Umstand, dass der Analyst seinen eigenen Messdaten keinen Zweifel mehr entgegenzubringen hat, ist ein erheblicher Wert an sich.

5.5

Messung auf der Seite der Endgeräte Stehen alle diese Möglichkeiten nicht zur Verfügung ... •

Mirror Port

•

Repeater/Ringleitungsverteiler

•

Media Tap/Media Splitter

... so muss über andere Messpunkte bzw. Messtechniken nachgedacht werden.

5.5.1

Und wieder: Shared Media LAN Es können Messungen in den Arbeitsgruppen durchgeführt werden; sofern diese noch über Shared Media LAN arbeiten; schließlich machen sich die beanstandeten Fehler (meistens) bei den Mitarbeitern am Arbeitsrechner bemerkbar. Hier können die Messungen in der Regel ohne Eingriff vorgenommen werden, da die meisten Arbeitsrechner (noch) nicht über Full-Duplex-Adapter verfügen. Falls doch, müsste zwar auch hier eine Herabstufung auf half-duplex erfolgen; hier aber ist der Eingriff systematisch als sehr unbedeutend anzusehen, weil •

die verbleibenden Arbeitsrechner hiervon nicht betroffen sind und somit alle anderen Datendialoge beim Server ohne nennenswerte Veränderung zum vorigen Zustand stattfinden,

•

Arbeitsrechner selten mehr als einen Datendialog gleichzeitig führen, was übrigens Full-Duplex-Anschlüsse am Endgerät weitgehend fruchtlos macht (siehe unten).

Wie auch immer: Messungen am Arbeitsgruppenverteiler der Client-PCs gibt in jedem Falle Aufschluss darüber, ob die Dialoge auch korrekt geführt werden; Fehler z.B. in den Kommunikationstreibern und/oder Applikationen würden in jedem Falle sichtbar. Auch könnten ggf. Verzögerungen in der Antwortzeit des Client-PCs nachgewiesen werden. Könnten nach einer solchen Messung derartige Fehler des Client-PCs mit Sicherheit ausgeschlossen werden, wäre klar, dass verlängerte Antwortzeiten ihre Ursachen woanders hätten: •

am Server, oder

•

an den aktiven LAN-Komponenten (Bridges, Switches, Router), oder

•

an zu langsamen WAN-Verbindungen.

132

Eingriff ins System: Gefährlich!

Wäre dieser Rückschluss mit Sicherheit gegeben, könnten die weiteren Messungen bzw. der dafür erforderliche Aufwand genauer kalkuliert und abgewogen werden.

5.5.2

Eingeschränkter Nutzen des Full-Duplex-Betriebes Exkurs: Full-Duplex-Anschlüsse erlauben dem jeweiligen Gerät, meistens Servern, gleichzeitig zu senden und zu empfangen. Dies setzt zur sinnvollen Nutzung voraus, dass Datenpakete (Frames) eintreffen, während gesendet wird oder werden soll. Dies ist aber für die meisten Client-Operationen völlig belanglos, weil sie in aller Regel nur mit einem Prozess auf einen einzigen Server zugreifen. Full-DuplexBetrieb wäre beispielsweise bei einer Dateiübertragung fast völlig wirkungslos. Der einzige theoretische (und praktisch wohl kaum noch messbare) Nutzen wäre dann gegeben, wenn die Empfangsquittungen (ACK) des Servers just einträfen, wenn gerade noch ein Paket an den Server gesendet würde. Der Zeitvorteil in der Verarbeitung eines Server-ACK läge maximal in der Dauer eines gesendeten Pakets. Zwischen einem Full-Duplex-Dialog und einem Half-Duplex-Dialog würde der Client also entweder keinen oder keinen spürbaren Unterschied erleben. Der Nutzen von Full-Duplex-Anschlüssen liegt ganz auf der Seite der Server. Beispiel: Ein Server führt mit vielen Clients gleichzeitig Datendialoge mit gleichzeitigen Sende- und Empfangsvorgängen (simultanes Tx-Rx): Während der eine Client eine Datei auf dem Server speichert (dem Server also Daten schickt), kann der andere Client eine Datei vom Server lesen (sie sich also vom Server schicken lassen). Und selbst diese Bedingung eines Nutzens von Full-Duplex-Anschlüssen scheitert in der Praxis manches Mal daran, dass der angesprochene Server (eben: aufgrund des Full-Duplex-Anschlusses !!) dermaßen überlastet ist, dass seine Antwortzeiten überlang sind.

5.6

Eingriff ins System: Gefährlich! Ergeben sowohl die Messungen auf der Client- wie auch auf der Server-Seite keine erkennbaren Fehler (was sehr selten ist), nachdem auf beiden Seiten die ursprünglichen Einstellungen verändert worden waren (Umstellung von vollduplex auf halb-duplex), so ist damit indirekt der Nachweis geführt, dass Verzögerungen bzw. Fehler nur im unveränderten Zustand stattfinden, also dann, wenn die Daten über Full-Duplex-Ports laufen.

Kapitel 5 • Switches und Mirror Ports

133

In diesem Falle kann mit einiger Sicherheit davon ausgegangen werden, dass die beteiligten Switches und/oder Endgeräte mit dem Full-Duplex-Verkehr nicht zurechtkommen. Allerdings wäre damit noch nicht gesagt, ob es sich um einen technischen Fehler der Switches handelt oder um schiere Überlastung der Endgeräte.

5.7

Messungen am Switch: Media Tap! Das Ergebnis lautet darum in letzter Konsequenz: Zuverlässige Messungen unter allen Bedingungen sind nur mittels Media Tap/Media Splitter zu erreichen. Angesichts des sehr übersichtlichen Angebots auf dem Markt darf der vermutlich führende Hersteller noch einmal genannt werden: Shomiti, USA http://www.shomiti.com/

Kapitel 6 Notfallmessungen 6.1 6.2

Abgestimmtes, gemeinsames Vorgehen! Online-Fragebogen im Internet

136 140

136

Abgestimmtes, gemeinsames Vorgehen!

Die folgenden beiden Abschnitte richten sich sowohl an Dienstleister, die als Externe LAN-Analyse durchführen (wie der Autor), als auch an die Betreiber von LANs; beiden sollte klar sein, dass eine möglichst sinnvolle, reibungslose Zusammenarbeit mit Arbeitsteilung erreicht werden muss, wenn der Schaden möglichst klein gehalten und der Fehler möglichst schnell gefunden werden soll.

6.1

Abgestimmtes, gemeinsames Vorgehen! Der folgende Text in den Abschnitten 6.1.1 und 6.1.2 wird Kunden des Autors per Fax oder E-Mail zugesendet, wenn eine Notfallmessung in ihrem Hause ansteht, damit bestmögliche Koordination der Arbeiten erreicht werden kann.

6.1.1

Angaben zum Störfall/Analysefragebogen Es ist unbedingt wichtig, dass wir vorab so viel Information über den Störfall erhalten, wie nur eben möglich. Dies erhöht die Trefferwahrscheinlichkeit bzw. verkürzt die entsprechenden Arbeiten bei Ihnen vor Ort ganz erheblich. Schon die Wahl der Messgeräte hängt von Ihren Auskünften zum Fehlerszenario ab. Hierzu sind folgende Arbeitsschritte notwendig: 1. Sie füllen bitte als Erstes unseren Analysefragebogen aus. 2. Sie übersenden uns bestimmte Teile Ihrer Netzwerkdokumentation. Darunter vor allem: – Lageplan/Topographischer Plan – Liste aller Server (File-, Print-, Communication-) mit den IP-Adressen und Rechnernamen. – Liste der Arbeitsgruppen (Win95/98, WinNT, NetWare NDS).

6.1.2

Ansprechpartner/Vorbereitungen Ihrerseits Nach Erteilung Ihres Auftrages und nach Absprache treffen Sie bitte in Ihrem Hause die folgenden Vorbereitungen: 1. Einer Ihrer Mitarbeiter wird für die gesamte Dauer unserer Messung abgestellt. 2. Dieser Mitarbeiter muss Zugang zu allen relevanten Dokumenten haben (Netzwerkdokumentation). 3. Dieser Mitarbeiter muss Zugang haben zu allen Räumen, die LAN-Anschluss bzw. mit dem Störfall zu tun haben. 4. Es muss sichergestellt sein, dass zur Mittagspause so viele RZ-Mitarbeiter wie nur irgend möglich an der großen Lagebesprechung (s.u.) teilnehmen können.

Kapitel 6 • Notfallmessungen

137

5. Falls es eindeutig identifizierbar einige Anwender gibt, die besonders häufig unter dem Fehler zu leiden haben, müssen diese auf ihre Bereitschaft hin befragt werden, zeitweise als »Versuchskaninchen« zur Verfügung zu stehen. Es erhöht die Trefferquote (bzw. verkürzt die Suchzeit) erheblich, wenn unmittelbar neben einem betroffenen Mitarbeiter gemessen werden kann. Dies gilt umso mehr, wenn der Fehler reproduzierbar ist. Für diesen Fall gilt: Es muss am Arbeitsplatz dieses Anwenders eine zusätzliche LAN-Buchse frei sein. 6. Im RZ bzw. am Verteilerschrank muss für jedes infrage kommende LAN-Segment mindestens ein (Mirror)Port für unsere Messgeräte frei sein. (»Frei« im Sinne von: Die Buchse muss frei sein, bei Managed Hubs darf keine Restriktion auf den Port gelegt sein, z.B. über die zugelassene MAC-Adresse.)

6.1.3

Wie es losgeht = Warum wir wenig reden Wir kennen aus Erfahrung den beim Kunden bestehenden Mitteilungsbedarf. Wenn es wirklich »brennt« und wenn die Verluste 6- oder 7-stellig werden, ist die Nervosität sehr groß, und schnell wird der Fall im Hause des Kunden auch »politisch«. Wir sehen grundsätzlich davon ab, uns davon bei Eintreffen beim Kunden beeinflussen zu lassen. Wichtig ist allein Folgendes: 1. So schnell wie möglich die Messrechner anschließen. 2. Wenn wir mit mehr als einem Messrechner anrücken, wird einer auf Dauermessung eingestellt, mit dem zweiten werden gezielte Kurzzeitmessungen gemacht, die allein dem folgenden Zweck dienen: 3. Überblick verschaffen! Aus Erfahrung gehen wir (ohne Unfreundlichkeit!) davon aus, dass die Dokumentation unseres Kunden unvollständig oder fehlerhaft ist bzw. sein könnte. Denn: Was könnte der Grund dafür sein, dass die Lage so verfahren ist? Das hat oft mit Handlungen des Kunden zu tun, deren Folgen er sich wegen unvollständiger/unrichtiger Dokumentation nicht bewusst sein konnte. Außerdem umfasst die Dokumentation des Kunden regelmäßig auch nicht das, worauf es uns ankommt. Die ersten Viertelstunden dienen allein dem Zweck, uns einen Überblick zu verschaffen und unsere eigenen Erkenntnisse mit den Vorabangaben des Kunden abzugleichen (Verifikation). Zu groß ist die Gefahr, dass der Kunde uns ungewollt eine falsche Fehlerursache nennt. Erst danach ist die Grundlage für die eigentliche Messung gegeben. Allerdings verschafft der »erste Blick« oft schon greifbare Anhaltspunkte. Nach dem »ersten Blick« gilt: Jetzt erst wird geredet.

138

6.1.4

Abgestimmtes, gemeinsames Vorgehen!

Runder Tisch: Alle müssen da sein! Nachdem die Vorarbeiten abgeschlossen sind (Überblick, Abgleich mit den Angaben der Kunden) und während mindestens ein Messrechner im Dauerbetrieb weiterarbeitet, muss geredet werden. Typischerweise findet die erste große Lagebesprechung beim Mittagessen statt: Das spart Zeit, und vor allem: Üblicherweise sind zur Zeit der Mittagspause alle Mitarbeiter verfügbar; nur zu dieser Zeit sind alle »frei«. Sollten die IT-Aufgaben auf verschiedene Abteilungen verteilt sein (z.B. LANTechnik, Server/RZ, PC-Endgeräte, Applikationsprogrammierung, etc.), so müssen aus allen Abteilungen fachkundige Mitarbeiter anwesend sein; diese müssen zugleich die Berechtigung haben, auf relevante Daten und Dokumentationen zuzugreifen. Grund der »großen Lagebesprechung«: Die Erfahrung zeigt, dass bei vielen Störfällen das zur Lösung notwendige Wissen durchaus im Hause des Kunden vorhanden ist – es ist aber auf so viele Köpfe verteilt, dass es erst (wieder) zusammengefügt werden muss. Oft wissen die Mitarbeiter auch nicht, dass sie dieses Wissen haben bzw. ihnen ist nicht bewusst, wie sie es zusammensetzen können. Dieses Gespräch ist wichtig! Hier wird die weitere Vorgehensweise durchgesprochen; die ersten Erkenntnisse unserer Stichproben bzw. unseres Überblicks werden vorgetragen und mit den Kenntnissen Ihrer Mitarbeiter abgeglichen; weitere Aufgaben werden verteilt, z.B. zur Beschaffung zusätzlicher Dokumentation aus Ihrem Hause.

6.1.5

Weitere Vorgehensweisen Für den Fall, dass der Fehler – mehr oder weniger – reproduzierbar ist, dürfte mit einer eher geringen Dauer unserer Arbeit zu rechnen sein – nach einem oder zwei Tagen dürfte erfahrungsgemäß mit einem befriedigenden Ergebnis zu rechnen sein. Anders verhält es sich, wenn der Fehler nur sporadisch auftritt. Dann können Langzeitmessungen anstehen; es kann vorkommen, dass dann nur noch einer unserer Mitarbeiter vor Ort bleibt (sofern wir mit mehreren Mitarbeitern angerückt waren); möglich ist auch, dass wir einen oder mehrere Messrechner bei Ihnen auf Dauermessung einstellen und abrücken – bis Sie dann wieder einen Störfall hatten. In diesem Falle würden die Messrechner an uns zurück geschickt zur Auswertung der Daten. Je nach Szenario kann es notwendig werden, eine Drei-Punkt-Messung durchzuführen. Erster Messrechner neben dem Server, zweiter Messrechner im LAN-Backbone, dritter Messrechner neben einem Anwenderarbeitsplatz (Workgroup).

Kapitel 6 • Notfallmessungen

139

Unsere Aufwandsabschätzungen hängen einerseits von Ihrer Vorab-Information ab (s.o.), andererseits vom Hergang unserer Messung am ersten Tage (s.o.).

6.1.6

Der Messbericht Sie erhalten von uns einen Arbeitsbericht, aus dem alles Notwendige hervorgeht. Es handelt sich hierbei um HTML-Dokumente mit Screen-Shots unserer Messrechner sowie erläuternden Kommentaren, die das nötige Verständnis für Fehlerablauf und -behebung vermitteln. Der Abschlussbericht enthält immer Erläuterungen zu drei Elementen: 1. Ausgangslage/Methodik 2. Fehlerdiagnose 3. sofern erkennbar: Fehlertherapie

6.1.7

Reaktionszeit verkürzen = Teamarbeit! Sofern eben möglich, entsteht dieser Bericht schon während der Messarbeiten. So sind wir schon bei Ihnen auf dem Campus in der Lage, Ihnen in Arbeitspausen die bisherigen Ergebnisse nachvollziehbar darzustellen. Es ist ggf. auch möglich, die jeweils bis dahin gewonnenen Erkenntnisse bzw. die bis dahin entstandenen Berichtsdateien auf einen Ihrer LAN-Server (oder einen unserer Laptops) zu kopieren, damit sie allgemein zugänglich werden. Auf diese Weise können noch während unserer Arbeiten weitere Mitarbeiter Ihres Hauses zusätzliche Unterstützungsarbeit leisten (in aller Regel Dokumentationsbeschaffung bzw. Abfrage von Gerätekonfigurationen). Anders gesagt: Wir stellen unsere Messberichte noch während der laufenden Arbeiten online in Ihrem Intranet zur Verfügung und erzeugen gewissermaßen ein »Multi-Tasking«, insofern wir verschiedene Arbeiten auf verschiedene Schultern bzw. Köpfe verteilen können.

6.1.8

Schnell ans Ziel gelangen! Unsere gesamte Arbeitsweise ist darauf ausgerichtet, mit definitiv kürzestmöglicher Zeit das bestmögliche Ergebnis zu erzielen, nämlich: die Wiederverfügbarkeit Ihres Netzwerkes zu sichern. Dazu aber benötigen wir – wie beschrieben – Ihre Mithilfe.

140

6.2

Online-Fragebogen im Internet

Online-Fragebogen im Internet Im Internet gibt es zur möglichst guten Vorbereitung der Messung einen OnlineFragebogen (http://www.synapse-services.de/), der durchaus geeignet ist, einen hinreichenden Eindruck von der Art des Problems zu geben sowie von der vermutlich sinnvollsten Herangehensweise; auch ist die Abschätzung des Personalaufwandes mit Hilfe dieser Angaben besser.

Abb. 6.1: Der Online-Fragebogen (1/7)

Kapitel 6 • Notfallmessungen

Abb. 6.2: Der Online-Fragebogen (2/7)

141

142

Online-Fragebogen im Internet

Abb. 6.3: Der Online-Fragebogen (3/7)

Kapitel 6 • Notfallmessungen

Abb. 6.4: Der Online-Fragebogen (4/7)

143

144

Online-Fragebogen im Internet

Abb. 6.5: Der Online-Fragebogen (5/7)

Kapitel 6 • Notfallmessungen

Abb. 6.6: Der Online-Fragebogen (6/7)

145

146

Online-Fragebogen im Internet

Abb. 6.7: Der Online-Fragebogen (7/7)

Kapitel 7 Kritik der LAN-Architekturen 7.1 7.2 7.3 7.4 7.5

Kritik des Shared Media LAN Das Funktionsprinzip herkömmlicher LANs SAN statt LAN bei der Datenhaltung IPv6, RSVP, L3-Switching, Network Policy Fazit

148 151 157 158 161

148

Kritik des Shared Media LAN

Dieses Kapitel soll grundsätzlich die Frage beleuchten, welche Faktoren die Leistungsfähigkeit »des Netzes« beeinflussen bzw. welche Faktoren für die gewünschten, kurzen Antwortzeiten sorgen. Inhalt dieses Abschnitts ist: •

LAN-Trends/LAN-Architekturen

•

Bestandsaufnahme: Kritik am Shared Media LAN

•

Shared Media vs. Switched Networks

•

Zukünftige LAN-Architekturen

Es hat wenig Wert, mit der ausgefeiltesten LAN-Analyse auch noch die exotischen Fehler aufzuspüren, wenn schon die Gesamtarchitektur nicht stimmt.

7.1

Kritik des Shared Media LAN

7.1.1

LAN – Last Area Network Shared Media sind im Backbone überholt Herkömmliche LANs mit Ethernet (10 Mbps) und Token Ring (8/16) sind für den Einsatz im Backbone endgültig überholt. Selbst Fast-Ethernet mit 100 Mbps ist im Backbone oft schon problematisch. Ansonsten haben sie ihre Zukunft hinter sich, weil sie Shared Media LANs sind. Nur im Anschlussbereich der Endgeräte mag es sie noch geben (dort aber noch lange Zeit). Der PC-Anschluss ist die »Last Area« von Shared Media LANs Ethernet und Token-Ring bleiben noch lange die ausreichenden Techniken zum Endgeräteanschluss. 10 Mbps/16 Mbps reichen immer noch für viele Endgeräte, ansonsten gibt es 100 Mbps (Fast Ethernet). Shared Media LANs benutzen (mehr oder weniger) spontane Zugriffsmethoden (MAC=Media Access Control), mit denen die zur Verfügung stehende Übertragungszeit bzw. die verfügbare Bitrate (available bit rate, ABR) auf die angeschlossenen Stationen verteilt wird. Diese herkömmlichen MAC-Methoden sind für Netzwerk-Backbones (Trunks) völlig unbrauchbar. WAN- und Telefontechnik erobert das LAN-Backbone Techniken, die für WAN-Verbindungen bzw. für ISDN entwickelt wurden, strahlen auf die Entwicklung auf dem Campus aus (»LAN« wäre hier endgültig die unzutreffende Bezeichnung):

Kapitel 7 • Kritik der LAN-Architekturen

•

ATM

•

IPv6 (IPng)

•

IP Switching, IP Tag Switching, Fast IP, RSVP, RTP etc.

149

Echtzeitübertragung, QoS (Quality of Service), ToS (Type of Service) sind Merkmale, die ursprünglich in Sprachnetzen eingeführt wurden. Diese Merkmale »erobern« nunmehr in hohem Tempo das Corporate Backbone auf dem Campus – Stichwort: VLAN. Die Folge davon ist: Herkömmliche LANs haben im Corporate Backbone/Campus Backbone nichts mehr zu suchen. Entsprechend enthalten die Backbone-Techniken auch keine echten LAN-Techniken mehr, sondern nur noch etwas, was dafür ausgegeben wird, damit die Kundschaft nicht verunsichert wird. Wenn ein Fast Ethernet Backbone oder Gigabit Ethernet Backbone wirklich noch mit CSMA/CD arbeiten würde, wäre es praktisch zum Dauerkollaps verurteilt. Die modernen Backbone-Techniken sind insofern keine eigentlichen LAN-Techniken mehr, wie sie keine Shared-Media-Techniken mehr sind. SAN-Technik verdrängt LAN-Technik im RZ SAN = Storage Area Network Langsam, aber sicher entwickelt sich Fibre Channel (FC) zur festen Größe im Rechenzentrum. File Sharing der alten Art hat in der Zukunft ausgedient: Früher (teilweise heute noch) •

wurden immer neue Festplatten-Kapazitäten auf immer mehr Server verteilt; und daher

•

wurden Daten zur Eigenschaft der Server, in/an denen die Festplatten montiert waren (sind); und daher

•

wurden bestimmte Daten immer nur über bestimmte Server erreicht; und daher

•

waren die Datenströme in der Server-Farm nie gleichmäßig verteilt;

•

es fehlt(e) das Load Balancing, das im SNA-Umfeld mit Token-Ring schon lange möglich war (ist).

Zukünftig (teilweise heute schon) •

können sich mehrere File Server denselben Plattenturm teilen;

•

kann möglicherweise Load Balancing im Server-Zugriff Wirklichkeit werden durch die Verwendung intelligenter VLANs bzw. intelligenter Protokolle;

150

Kritik des Shared Media LAN

•

werden SCSI-Protokolle genauso wie TK-Protokolle, LAN-Protokolle, VideoProtokolle über FC-Netze gehen;

•

werden FC-Inseln entstehen für Festplattentürme (RAID), Backup-JukeBoxen/Tape-Türme, Video-Zugriffe.

Die Folge ist: Herkömmliche LAN-Technik wird durch SAN-Technik verdrängt, da das Durchsatz-, Fehler- und Zugriffsverhalten der »alten« MAC-Protokolle (Ethernet, Token-Ring) für die Anforderungen im RZ bzw. im Server-Umfeld nicht länger geeignet sind. Das Backbone vor dem Server (anwenderseitig) wird dominiert sein durch ATM und Gigabit Ethernet (GE). Das Backbone hinter dem Server (speicherseitig) wird dominiert sein durch Fibre Channel (FC). Vorläufiges Fazit (1): LAN-Technik ist PC-Technik Ethernet und Token-Ring sind Techniken für den Endgeräteanschluss. Gigabit Ethernet ist kein echtes Ethernet mehr – es handelt sich hierbei um einen angepassten Fibre Channel, der Ethernet-Frames transportiert. Vorläufiges Fazit (2): LAN-Protokolle leben ewig Die alten LAN-Protokolle (Ethernet, Token-Ring) können im »Sandwich-Pack« überleben, wenn ... •

darunter (OSI-Layer 1) und/oder

•

darüber (OSI-Layer 3)

Anpassungen erfolgen. Zu den wichtigsten Entwicklungen dieser Art gehören: •

einheitliche Protokolle (ATM, IPv6)

•

einheitliche Adressierungen (ATM, IPv6)

•

Switching statt Shared Media

•

Virtual LANs statt Shared Media LANs

•

Gigabit statt Megabit (Backbone)

•

IPv6 statt IPv4

•

IP Switching/Layer-3 Switching statt IP Routing

•

RSVP, RTP etc. zur Echtzeit-Unterstützung

Kapitel 7 • Kritik der LAN-Architekturen

7.2

151

Das Funktionsprinzip herkömmlicher LANs Oder: Shared Media – Was stört daran? Nur ein Medium Alle Stationen im Netzwerk sind an dasselbe Übertragungsmedium (= Kabel, Funkfrequenz) angeschlossen. Forderung(en): Diese Einschränkung muss überwunden werden. Die hierfür gegebene Technik ist das LAN-Switching. Rundfunk Was eine Station sendet, wird von allen anderen »gehört«. Daher stammt auch die Bezeichnung: Broadcast-Netze (Rundruf-Netze). Es ist wie bei Radiosendern: Einer sendet, alle hören mit. Dies bedeutet nicht nur Leistungsverlust, sondern auch einen erheblichen Verlust an Sicherheit (Data Privacy). Forderung(en): Das Broadcast-Prinzip muss so weit wie möglich aufgehoben werden. Das LAN muss sicher sein. Niemand soll mithören können. Geteilte ABR (Available Bit Rate)/»Bandbreite« Anders gesagt: Alle Stationen teilen sich in Shard Media LANs das Medium bzw. die auf ihm zur Verfügung stehende •

Übertragungszeit

•

Datenrate

•

Bitrate (Available Bit Rate, ABR)

Warnung Missverständnis! Gerne wird von geteilter »Bandbreite« gesprochen. Das ist im Kern falsch, da »Bandbreite« ein verfügbares Frequenzspektrum beschreibt – was hier jedoch nicht zutrifft, da alle Teilnehmer im LAN mit derselben Frequenz senden. Wegen dieser Aufteilung der ABR auf viele Teilnehmer ist ein Mechanismus nötig, der eine faire Teilhabe aller Stationen erlaubt: •

MAC = Media Access Control.

152

Das Funktionsprinzip herkömmlicher LANs

Forderung(en): Die ABR soll jeder Station ungemindert zur Verfügung stehen. Sendebeschränkung: MAC = Media Access Control Es kann immer nur eine Station zu einer Zeit senden. Die Verteilung bzw. Zuweisung der Endgerätesendezeit erfolgt mehr oder weniger zufällig durch einen MAC-Mechanismus, der in keinem Fall zuverlässig genug ist für fortgeschrittene Applikationen wie etwa Voice-over-LAN. Allenfalls FDDI kennt als Shared Media LAN Möglichkeiten, Adaptern eine garantierte Sendeleistung zuzubilligen; das aber hat sich nicht durchgesetzt. Forderung(en): MAC soll sich nicht weiter störend bemerkbar machen. Shared Media LAN: nur begrenzt skalierbar Das Verhältnis von •

Zuwachs an angeschlossenen Endgeräten und

•

Zuwachs an tatsächlichem Datendurchsatz

ist nicht linear proportional. Das System kann nicht beliebig erweitert werden und entsprechend leistungsfähiger werden. Mit jeder neuen Station ... •

verliert das LAN an QoS (Quality of Service);

•

wird das Verhältnis von freier Übertragungszeit zur Zahl der Stationen immer schlechter;

•

wird das Durchsatzverhalten immer unberechenbarer;

•

werden die Laufzeitschwankungen immer größer (missverständlich oft als »Jitter« bezeichnet anstatt als »Packet Delay Variation«).

Forderung(en): Das LAN muss voll skalierbar sein – und damit zukunftssicher, um die Investitionen zu schützen, das Wachstum zu verkraften und neue Applikationen zu unterstützen. Daher müssen LANs weitgehend Switched Networks sein. Daher sollten LANs neben Durchsatz auch QoS bieten – was faktisch immer noch durch Überkapazität geleistet wird, solange keine VLAN-Techniken eingesetzt werden.

Kapitel 7 • Kritik der LAN-Architekturen

153

Keine Echtzeit- bzw. QoS-Garantie LANs bieten keine Gewähr dafür, •

dass die sog. Verzögerungszeit (= Signallaufzeit, Übertragungszeit) der Datenpakete immer genau gleich ist bzw.

•

dass die Laufzeit-Schwankungen (»Jitter«, »Packet Delay Variation«) in engen Grenzen bleiben.

Immer gleiche Verzögerungszeit (relativ zur aktuellen Session) bei kurzer Signallaufzeit insgesamt (absolut über alle Sessions hinweg) ist jedoch Voraussetzung für den Einsatz von Echtzeitanwendungen wie Telefonie und Videokonferenz. Bei Telefonie gilt eine Signallaufzeit von bis zu •

20 ms

als »sehr gut« (Ortsgesprach),

•

80 ms

als »gut« (Ferngespräch),

•

200–300 ms

als »befriedigend/ausreichend« (Internet-Telefonie).

Forderung(en): Einheitliche Signallaufzeit (Constant Bit Rate/Constant Delay). Der Datenfluss muss eindeutig bestimmbar sein (können). QoS sollte nicht allein durch Überkapazität geleistet werden. Deswegen sollten Protokolle wie VLAN 802.1p/Q, IPv6, IPv4+RSVP, RTP etc. verstärkt eingesetzt werden. Paketvermittlung Die Vermittlung von Datenpaketen mittels Router oder Switch verlangt, dass aus jedem Paket die Wege-Information herausgelesen wird. Warum eigentlich? Weil der Switch oder Router nicht erkennt, dass er schon für zig Tausend andere Pakete desselben Absenders an denselben Empfänger schon dieselbe Wegewahl getroffen hat. Warum erkennt der Switch oder Router das nicht? Weil nicht mit logischen Kanalnummern gearbeitet wird (wie bei: X.25, Frame Relay, ISDN, ATM), sondern mit MAC-Adressen und Netzwerkadressen. Forderung(en): Einheitliche, eindeutige, über alle Netze und Anwendungen hin identische Adressierung (ATM, IP-Tag) – wenigstens im Core Backbone bzw. Backbone Trunk. Was wichtig ist, liegt vorne in den ersten Bytes des Headers, damit die Vermittlungsknoten (Switches, Router) nicht so tief ins Paket hineinsehen müssen, und damit Hardware-Schaltungen unterstützt werden.

154

Das Funktionsprinzip herkömmlicher LANs

Es sollten Kanalkennungen statt der üblichen Adressen verwendet werden: Die logischen Verbindungen (Kanäle, Sessions) sollten gekennzeichnet werden, nicht der Weg des einzelnen Paketes. Diese Techniken sind in verschiedener Ausprägung vorhanden bei: •

ATM VPI/VCI

•

IP-Tags

•

VLAN-Tags

Protokollvielfalt/Wechselnde Adressformate Die Vermittlung von Datenpaketen herkömmlicher Art (z.B. mit IP, IPX, DDP, VIP etc.) verlangt, dass der Router erkennt, ... •

welches Routing-Protokoll im Frame vorliegt;

•

an welcher Position das Routing-Protokoll liegt.

So kann beispielsweise IPX (Novell NetWare) bei Ethernet an bis zu drei verschiedenen Stellen mit insgesamt max. vier verschiedenen Kombinationen im Frame liegen: A. B. C. D.

[14 [14 [14 [14

Bytes Bytes Bytes Bytes

ETH ETH ETH ETH

mit mit mit mit

Type ] Length] Length] Length]

+ + + +

[IPX] [IPX] [3 Bytes LLC] + [IPX] [8 Bytes LLC_SNAP] + [IPX]

Dabei wird bei der Verwendung des EtherType-Feldes für IPX die Protokollkennung 0x8137 genommen, bei Verwendung von LLC die SAP-Kennung 0xE0. Bei IP sind es zwar »nur« zwei Varianten, und nicht vier wie bei IPX, aber dennoch ist der Zweck einer Vereinheitlichung der Protokolle und Adressierungen wenigstens im Backbone unmittelbar einsichtig. Kein Router kann bei solchem Durcheinander schnell arbeiten! Forderung(en): Einheitliches, für alle Netze und Anwendungen identisches Protokoll mit einheitlicher Adressierung: •

ATM

•

IPv6

•

IP-Tag

•

VLAN-Tag

Kapitel 7 • Kritik der LAN-Architekturen

155

Ethernet vs. Token Ring Unterschiede und Gemeinsamkeiten: Ethernet Auf Bitraten-Zuweisung (= Senderecht) muss hier nicht gewartet werden; dafür werden Kollisionen in Kauf genommen und der damit einhergehende Zeitverlust. Die starke Unabhängigkeit der Adapter voneinander ist ein erheblicher Sicherheitsfaktor (im Gegensatz zu Token-Ring). Sendezeit steht immer ohne Zuweisungsmechanismus zur Verfügung – bis die Daten in einer Kollision verloren gehen und Daten neu gesendet werden müssen. Token Ring Ein Token (= Senderecht) regelt eine weitgehend faire Bitratenzuweisung; dafür beschäftigen sich die Adapter erheblich mit sich selbst. Ihre starke Abhängigkeit voneinander ist ein erhebliches Betriebsrisiko. Sendezeit wird überall angeboten (in Form des kreisenden Tokens) – auch dort, wo sie nicht benötigt wird. Für beide Techniken gilt: Sie verschwenden in ihren Shared-Media-Varianten Sendezeit bzw. Prozessorleistung. Hier durch Kollisionen, dort durch ungefragte Token-Angebote und ein umfangreiches MAC-Protokoll. Forderung(en): Sendezeit darf nicht verloren gehen durch Verlust (Kollision) oder Angebot dort, wo sie nicht gebraucht wird (Token); sie muss seitens der Endgeräte gegenüber dem LAN-Switch abgefragt bzw. angefordert oder angekündigt werden. Die allgemein gängige Bezeichnung hierfür lautet Bandwidth On Demand – was besser mit Bit-rate On Demand bezeichnet wäre. Um dann aber auch die Bitrate bzw. den Zeitschlitz bzw. den Switch-Puffer zur Verfügung stellen zu können, muss der Switch entweder wissen, dass der Bedarf da ist (entweder ATM mit Verbindungsaufbau oder 100VG-AnyLAN), oder er muss über erhebliche Warteschlangenpuffer verfügen. Längenbeschränkungen (Signallaufzeit) Aus der Eigenart, Broadcast-Netz mit Shared Media zu sein, folgen letzten Endes Längenbeschränkungen im Zusammenhang mit den maximal zulässigen Signallaufzeiten, die in Abhängigkeit zur Signalausbreitungsgeschwindigkeit auf dem jeweiligen Medium maximal zulässige Längen der LAN-Segmente nach sich ziehen.

156

Das Funktionsprinzip herkömmlicher LANs

Warnung Längenbeschränkungen einzelner Kabel wg. Dämpfung des Signals sind nicht zu verwechseln mit der hier gemeinten Beschränkung des LAN-Durchmessers durch die höchstzulässige Signallaufzeit [round trip delay] ! Die Beschränkungen können = müssen mit Switches und Routern überwunden werden. Forderung(en): Nicht mehr mit MAC-Funktionen herkömmlicher LANs arbeiten (= spontanen Zugriffsmethoden), die ebenfalls u.a. für die Längenbeschränkungen verantwortlich sind. Diese Forderung gilt nicht zwingend für den Endgeräteanschlußbereich; sie muss aber im Core Backbone umgesetzt werden. Grund: Bei Ethernet ist die Mindestpaketlänge von 64 Byte an die Begrenzung der Signallaufzeit gekoppelt (Slot Time = 25,6 µs) zwecks Ermöglichung der Collision Detection. Laufzeitverluste: die WDM-Alternative Herkömmliche Router/Switches arbeiten elektronisch. Die dabei notwendig anfallenden Umwandlungen und Verarbeitungen kosten Zeit: •

Optik → Elektronik

•

seriell → parallel

•

Längenerkennung/Speicherzuweisung

•

Adresserkennung

•

Serviceerkennung

•

Table LookUp

•

Port-Mapping

•

seriell ←parallel

•

Optik ← Elektronik

Lange Signallaufzeiten sind schon in Datennetzen unangenehm, in Sprachnetzen dagegen vollkommen intolerabel. Trotz der oben aufgestellten Forderungen kann gesagt werden, dass die Zukunft den WDM-Netzen gehören könnte: •

WDM = Wavelength Division Multiplexing

Die schnellsten Gigabit-Ethernet-Switches arbeiten bereits mit dem vom WDM her entwickelten Abkömmling SDM und erreichen über 50 Gbps.

Kapitel 7 • Kritik der LAN-Architekturen

•

157

SDM = Space Division Multiplexing

Reine Optiknetze haben zudem den Vorteil, dass neue Protokolle bzw. neue Bitraten leicht implementiert werden können, während bei TP-Kabeln das feste Verhältnis von Drill-zu-Frequenz-zu-Kodierung Grenzen setzt. Forderung(en): Rein optische Netze (WDM):

7.3

•

optische Signale

•

mehrere Signale auf einem LWL/MultiMode

•

rein optische Verstärker & Vermittlungsknoten

•

keine opto-elektronische Wandlung

•

keine Seriell-Parallel-Wandlung

•

daher keine Verzögerung mehr bei Durchlaufen der Knoten

SAN statt LAN bei der Datenhaltung Ist Fibre Channel (FC) möglicherweise das Universalmedium der Zukunft? Das ist ungewiss; es gibt Gründe, die dafür sprechen, und solche, die dagegen sprechen. Jedenfalls gibt es heute schon Storage Area Networks (SANs). Für Fibre Channel spricht, dass es viele Techniken bzw. Anwendungen unterstützt: •

LWL/Optik-Switches und Kupfer/Elektronik-Switches

•

SCSI, LAN-Protokolle, TK-Protokolle und Video-Stream

•

Festplatten, Tape-Streamer (Juke-Box), Server etc.

•

Punkt-zu-Punkt-Kanäle und Arbitrated Loop (Ring)

•

dezentrale Datenhaltung

•

Video-Übertragung (Echtzeit) mit FC ist besser als mit ATM

Gegen Fibre Channel spricht, dass immer noch praktische Einschränkungen gegeben sind, die dem breiten Einsatz entgegenstehen: •

FC-Produkte konzentrieren sich auf SCSI-Anwendungen

•

LAN-Adapter sind zwar verfügbar, aber kaum verbreitet

•

Die Server-Systeme für FC entstehen erst noch

•

FC als Ressourcen-Netzwerk ist (noch) kaum bekannt/akzeptiert

158

IPv6, RSVP, L3-Switching, Network Policy

FC: langfristige Konsequenzen Folgende Erwartungen verknüpfen sich mit FC: •

Das Spiegeln/Replizieren von Daten wird erleichtert.

•

Das Datenreplikat muss nicht im selben Raum/Gebäude sein, noch nicht einmal in derselben Stadt, was übrigens gerade in den USA bzw. in Kalifornien wegen der Erdbebengefahr von Belang ist.

•

Der Plattenstapel muss nicht beim Server sein, sondern kann ausgelagert werden.

•

Platten und Streamer (etc.) tauschen Daten direkt untereinander aus, was die Datensicherung immens beschleunigt.

Realistische Erwartungen sind: •

Externe Dienstleister bieten Data Hosting, also externe Speicherdienste an.

•

Sicherheitsbedenken werden langfristig wohl überwunden, wenn der Datendienstleister – bessere Brandschutzvorrichtungen hat etc., – Online-Replizierung der Daten in Echtzeit anbietet, – lückenlose/zeitnahe Datensicherung ermöglicht, – mehrere getrennte regionale Standorte hat, – zuverlässigere Störfallreaktionen hat, – und zudem viel billiger ist.

•

Viele Server greifen auf dieselben Massenspeicher zu; beim LAN-Zugang zu den Servern kann Load Balancing einführt werden.

•

Domain-Einschränkungen bei WinNT werden so umgehbar.

•

Datensicherung: Mit max. 1 Gbps von Festplatte zu Streamer.

Eine mögliche Perspektive kann zusätzlich in ferner Zukunft sein: •

7.4

Server verschiedener Betriebssysteme teilen sich dieselben Daten bzw. denselben Plattenstapel.

IPv6, RSVP, L3-Switching, Network Policy Neben der schieren Geschwindigkeit, die wesentlich der Physical Layer zur Verfügung stellt, steht das Faktum, dass trotzdem Bitraten auf der Leitung endlich begrenzt sind.

Kapitel 7 • Kritik der LAN-Architekturen

159

Es kann auch nicht erwartet werden, dass flächendeckend in neue, teure Hardware umgerüstet wird. Dies rückt logische Mechanismen in den Blick, mit denen die knappen Güter »Bitrate«, »Zeitschlitz« und »Switch-Puffer« gerechter bzw. angemessener verteilt werden sollen.

7.4.1

QoS, Echtzeit etc. – wer erhält welche Dienstgüte? Gefordert werden mittelfristig von Ende-zu-Ende-(Endgerät-zu-Endgerät) Verbindungen mit einer Dienstgüte, die für Voice/Video-over-IP geeignet sind. Dafür müssen im Netzwerk Ressourcen reserviert bzw. frei gehalten werden: •

reservierte Bitraten auf der Leitung

•

priorisiertes Queueing/Forwarding in Switches & Routern

Hierzu muss es Datenströme »1. Klasse« und »2. Klasse« geben. Die priorisierten Datenströme müssen in einer »Policy« definiert werden. Es ergibt sich die Frage: Woran wird die Priorisierung innerhalb der Policy festgemacht? •

An der MAC-Adresse bzw. am Anwender? Was, wenn dieser unterschiedliche Applikationen verwendet?

•

An der VLAN-Zugehörigkeit? (Closed User Group?) Was, wenn unterschiedliche Anwender unterschiedliche Applikationen unterschiedlicher Priorität verwenden?

•

An der IP-Subnet-Kennung? Also ggf. am Standort? Was, wenn die IP-Adressen nicht zugleich die QoS-bedürftigen Verbindungen kennzeichnen? RSVP implementieren? IPv4-ToS verwenden? Welche Applikationen verstehen das?

•

Am TCP/UDP-Port? Also an der Applikationskennung? Was, wenn unterschiedliche Funktionen der Applikation unterschiedliche Priorität haben?

7.4.2

Policy Based Networks Policy Based Networks sind Netzerke, die in ihrem Verhalten insgesamt oder doch weitgehend vordefinierten Festlegungen folgen, wobei auf die Bedürfnisse der Anwender oder Applikationen abgestellt wird. Im Zentrum stehen hierbei kurze Antwortzeiten und möglichst geringe Laufzeitschwankungen für EchtzeitAnwendungen.

160

IPv6, RSVP, L3-Switching, Network Policy

Die Frage ist also: Kann ein Policy Based Network wirklich die richtigen Anwender bzw. Anwendungen schützen bzw. bevorzugen? Die Vermutung liegt nahe: Nur zum Teil (vl. dem größeren Teil) wird Priorisierung mit Ressourcen-Reservierung Echtzeitfähigkeit bzw. Übertragung ohne Schwankung der Laufzeiten garantieren – letzten Endes wird immer auch Überkapazität notwendig sein, um den gewünschten QoS zu garantieren.

7.4.3

Netzwerkmanagement Zum schon heute üblichen Netzwerkmanagement werden zusätzlich folgende Faktoren kommen: •

Bandbreitenverwaltung = Bitratenzuteilung

•

QoS-Verwaltung

•

Policy-Pflege

Nicht der seltene Netzwerkausfall ist der Fehler, sondern der Netzwerknormalfall ist der Fehler, da täglich die Arbeit durch folgende Faktoren behindert wird: •

zu hohe Auslastung

•

zunehmende Schwankungen in der Paketlaufzeit

•

Abnahme des QoS wegen der Überlast

•

zu viele Teilnehmer mit hohen QoS-Anforderungen

Netzwerkmanagement und Netzwerk-Monitoring (RMON) verlangen daher letztlich die stetige Überwachung der

7.4.4

•

QoS Conformance;

•

Policy Conformance.

VLANs, Netzwerk- und Projektmanagement VLAN-Definition ist Aufgabe des Netzwerkmanagements Die Definition virtueller LANs (VLANs) über das gesamte Unternehmensnetzwerk hinweg ist Aufgabe des Netzwerkmanagements. VLANs haben auch mit Sicherheit zu tun – nicht nur die alten Firewall-Systeme, die sich hierauf einzustellen haben. VLAN-Server werden mit den Firewall-System nach und nach verschmelzen. Workgroup-/Workflow-/Projektmanagement Gerade bei kundenorientierten Herstellern und Dienstleistern, die hart im Wettbewerb stehen, werden diese Elemente immer wichtiger.

Kapitel 7 • Kritik der LAN-Architekturen

161

Integriertes Arbeiten aller Unternehmensbereiche zur schnellen Bedienung von Kundenanfragen verlangt: •

schnelle Verfügbarkeit der erforderlichen Datenquellen, und zwar unabhängig vom Server-Betriebssystem und den einzelnen Benutzereinträgen;

•

ggf. revisionssicheres Logging aller Arbeitsschritte über alle Abteilungsgrenzen hinweg etc.

Die Folge eines solchen erweiterten Verständnisses ist, dass folgende Elemente immer weniger zu trennen sind bzw. ihre Administration immer weiter zusammenrückt: •

Verwaltung von Projektgruppen

•

Verwaltung von Benutzern und Benutzergruppen an den Servern

•

Verwaltung der Datenquellen

•

Verwaltung der VLANs

•

Verwaltung der Firewall-Rechner

Dieses alles muss letztlich praktisch intuitiv mit wenigen Arbeitsschritten an der Management-Console einzurichten sein. Damit verschmelzen Netzwerkmanagement und Projektmanagement, VLANDefinitionen und Firewall-Definitionen und so weiter. Es erscheint nicht ausgeschlossen, dass in einiger Zukunft das Network-Logon nicht mehr gegenüber einzelnen Servern oder Domänen erfolgt, sondern nur noch zentral gegenüber dem VLAN-Server (der selber keine Daten hält mit Ausnahme von Authentisierungsdaten).

7.5

Fazit Es konnten verschiedene Merkmale herausgearbeitet werden, die für oder gegen alte oder neue Techniken sprechen. Es soll kurz zusammengefasst werden: Die Forderungen an Netze der Zukunft sind: • Verzicht auf Shared Media; stattdessen Switched Networks •

einheitliche Protokolle (ATM, IPv6)

•

einheitliche Adressierungen (ATM, IPv6)

•

Virtual LANs statt Shared Media LANs

•

Gigabit statt Megabit (= Überkapazität bei fehlender QoS)

162

Fazit

•

IPv6 statt IPv4

•

IP Switching/Layer 3 Switching statt IP Routing

•

das LAN muss voll skalierbar sein

•

der Datenfluss muss Echtzeitapplikationen zulassen

•

IP Tag-Switching (IP-Tag statt langer IP-Adresse)

•

Switching durch Schaltung in der Hardware, nicht Software

•

Vereinheitlichung von Protokollen und Adressierungen (z.B. ATM, IPv6)

•

Was wichtig ist, liegt vorne in den ersten Bytes des Headers damit die Vermittlungsknoten (Switches, Router) nicht so tief ins Paket hineinsehen müssen (z.B. ATM-Header, IP-Tag).

•

Kanalkennungen: Die logischen Verbindungen (Kanäle, Sessions) werden gekennzeichnet, nicht der Weg des einzelnen Paketes

•

herkömmliche MAC-Funktionen auf Endgeräteanschluss beschränken

•

rein optische Netze (WDM) statt elektronischer Vermittlungsknoten

•

Integration von Workgroup/Workflow/Project/Network Management

•

QoS-Überwachung im Network Monitoring (SNMP, RMON)

Diese Ausführungen erheben nicht den Anspruch, in allem gültig zu sein; die Entwicklung schreitet viel zu schnell voran, als dass alles richtig vorhergesagt werden könnte. Gleichwohl dürften viele der hier genannten Elemente für die Planung und Migration von deutlichem Belang sein. In jedem Fall sollte vermittelt werden, dass Netzwerkanalyse auch schon im Konzept zukünftiger Handlungen (Umbau, Erweiterung etc.) stattfinden muss!

Kapitel 8 Das OSI-Modell 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11

Normierungen Protokolle = festgelegte Verfahrensregeln Die sieben Schichten Layer 1: Physical Layer 2: Data Link Layer 3: Network Layer 4: Transport Layer 5: Session Layer 6: Presentation Layer 7: Application Header, Trailer, Daten: SDU+PCI=PDU

164 165 166 166 167 168 169 171 171 172 173

164

Normierungen

Der Verfasser denkt positiv und geht davon aus, dass Sie das OSI-Modell kennen. Es soll hier nur in wenigen Worten das Nötigste erklärt werden für den unwahrscheinlichen Fall, dass Sie das Modell noch nicht kennen sollten. Vermutlich ist es so, dass Ihre berufliche Tätigkeit das OSI-Modell schon längst zum alltäglichen Bestandteil Ihrer Arbeit hat werden lassen – denn sonst wären Sie jetzt kaum in der Verlegenheit, dieses Buch zu lesen.

8.1

Normierungen Die Standards der heute gängigen Datenkommunikation wurden von folgenden Instituten und Vereinigungen vorgenommen: Organistation

Entwicklungen

IEEE

Institute of Electrical and Electronics Engineers LAN-Kommunikation; Beispiele: IEEE 802.1 p/Q VLAN IEEE 802.3 Ethernet IEEE 802.5 Token-Ring

ANSI

American National Standards Institute LAN/WAN-Kommunikation; Beispiele: ANSI FDDI ANSI Frame Relay ANSI Sonet (SDH)

ISO

International Standardization Organization Diese bei der UNO angesiedelte Institution hebt Standards von IEEE und ANSI auf die Ebene international rechtlich verbindlicher Normen.

Tab. 8.1: IEEE, ANSI, ISO

Es soll nicht unerwähnt bleiben, dass für fast jede Technik Herstellervereinigungen existier(t)en, die wesentlich das Material für die Arbeiten von IEEE, ANSI und ISO liefern. Diese manchmal nur für einen bestimmten Zweck gegründeten Vereinigungen sind darum oft nach einigen Jahren wieder verschwunden – was nicht bedeutet, dass sie gescheitert wären; es kann sein, dass sie überflüssig wurden, weil der angestrebte Standard durchgesetzt werden konnte.

Kapitel 8 • Das OSI-Modell

8.2

165

Protokolle = festgelegte Verfahrensregeln Es braucht also zur Protokollanalyse Kenntnisse der Verfahrensregeln, die von allen Kommunikationsteilnehmern einzuhalten sind. Nicht umsonst wurde für die Software-Treiber, die für die Datenkommunikation entwickelt wurden, ein Begriff aus der Diplomatensprache entlehnt: Dort befolgt man das »Protokoll« z.B., wenn man als Vertreter seines Landes irgendwo eine Ehrengarde abschreitet – ob man will oder nicht. Schwierig wird es dann, wenn nicht alle Hersteller exakt dieselben Regeln verwenden, oder wenn es ungewollt Abweichungen gibt. Solche Abweichungen können durch bestimmte Einstellungen eines Kommunikationsgerätes entstehen – und diese Einstellungen können •

vom Hersteller ungewollt sein

•

für den Kunden unsichtbar sein

•

vom Gerät selbstständig vorgenommen worden sein.

Es kann insbesondere bei Windows-Maschinen vorkommen, dass die »Protokolle« (also die festgeschriebenen Verfahrensregeln) auf einmal anders angewendet werden, als Sie dies erwarten. Windows-Maschinen erfinden natürlich nicht über Nacht ihre eigenen Protokolle – aber sie sind in der Lage, aus dem breiten Spektrum aller Möglichkeiten sehr spontan von den gesetzten Vorgaben abzuweichen und Fehler zu begehen. Dies liegt u.a. wesentlich in zwei Ursachen begründet: •

Der Versuch von Microsoft, ein Betriebssystem zu schaffen, das möglichst wenig manuelle Eingriffe erfordert und das sich möglichst selbst konfiguriert. Je weiter Microsoft in seinem Bemühen (das durchaus achtenswert ist) voranschreitet, umso größer werden die Möglichkeiten der Maschinen, sich selbstständig zu machen.

•

Microsoft hat wie manch anderer Hersteller auch die Schwierigkeit, nun bald 20 Jahre zu sich selbst abwärts (bzw. rückwärts) kompatibel zu sein. Auch dies ist eine Herausforderung, bei der Microsoft Opfer des eigenen Erfolges wird.

Das vorliegende Buch versucht darum, die Protokolle nicht nur in den OSISchichten, sondern so nah wie möglich am Betriebssystem von Windows (hauptsächlich WinNT) zu betrachten, damit die Zusammenhänge zwischen der Theorie der sieben Schichten und der Praxis der Windows-Systeme sichtbar und handhabbar werden.

166

8.3

Die sieben Schichten

Die sieben Schichten Die folgenden Abschnitte geben nur die grobe Orientierung; ansonsten wird auf die reichlich vorhandene Fachliteratur zu diesem Thema hingewiesen. Es wird vor allem auf die dem Buch beiliegende CD-ROM verwiesen, die mit dem »BANalyzer«-Projekt eine der vermutlich ausführlichsten Protokolldokumentationen enhält, die es zur Zeit gibt. Die Darstellungen des Programmes erklären ebenfalls das OSI-Modell und ordnen die Protokolle entsprechend ein.

8.4

Layer 1: Physical

8.4.1

Serielle Bitübertragung Die unterste Schicht ist die sog. Bitübertragungsschicht. Hier werden binary digits (Bit) seriell übertragen.

8.4.2

A/D-Wandler Die Schnittstellenadapter in den Rechnern (auch genannt: LAN-Adapter, NIC = Network Interface Card) prüfen die elektrischen bzw. optischen Signale im A/DWandler auf ihre Gültigkeit bzw. Deutungsfähigkeit (A/D = analog-von/zu-digital). Erst in der Deutung des A/D-Wandlers entsteht aus dem physikalischen Signal ein eletronisch in Transistoren und Kondensatoren abgebildetes Bit mit den Werten 0 oder 1. Je nach LAN-Technik können verschiedene physikalische Fehler erkannt und dem Betriebssystem des Rechners gegenüber gemeldet werden. Ethernet-Adapter erkennen eher wenig, Token-Ring-Adapter viel.

8.4.3

Prüfsummen Eine immer gegebene Prüfung findet mit dem sog. Cyclic Redundancy Check (CRC) statt. Jeder Absender von Daten versieht den Datenblock mit einem Prüfsummenwert; hierdurch wird für den Empfänger prüfbar, ob der Inhalt des eingegangenen Datenblocks einwandfrei erhalten wurde.

Kapitel 8 • Das OSI-Modell

8.5

167

Layer 2: Data Link Hier findet horizontal wie vertikal eine »Datenverbindung« statt: •

horizontal zwischen zwei Netzwerkteilnehmern, da in der Funktion dieser Schicht die Adressierung im lokalen Netz (LAN) stattfindet

•

vertikal zwischen dem Layer 2 sowie dem Layer 3, indem immer ein Data-Link Protocol die Kennung des im Datenpaket nachfolgenden Protokolls der nächsthöheren Schicht (meistens: Layer 3) enthält

Der Data Link Layer zerfällt in zwei Unterschichten:

8.5.1

•

Layer 2a: MAC = Media Access Control

•

Layer 2b: LLC = Logical Link Control

Layer 2a: MAC = Media Accress Control Da auf dieser Schicht die Regeln enthalten sind, die für alle Netzwerkteilnehmer verbindlich klären, wer wann senden und empfangen kann (darf), wird diese in der Hardware der LAN-Adapter sitzende Teilschicht von Data-Link MAC Layer genannt. Als Media Access Control wird die Zugangssteuerung zum Medium fürs Senden und Empfangen bezeichnet. MAC-Adressen Die Adressen der Adapter, die weltweit genormt sind, spielen eine zentrale Rolle im System von MAC, da jeder Mechanismus des Empfangens ohne sie wenig Sinn hätte. Die Adapteradressen werden darum allgemein als MAC-Adressen bezeichnet. MAC-Protokoll Manche LAN-Technik arbeitet so, dass sich die LAN-Adapter untereinander mit einem eigenen Protokoll verständigen. Dies ist traditionell bei den sog. TokenProtokollen so (bei denen ein Token genanntes Senderecht vergeben wird): ARCnet, Token-Ring, FDDI. Ethernet kennt dieses in dieser Form nicht. Das MAC-Protokoll von Token-Ring nimmt in diesem Buch einigen Raum ein.

8.5.2

Layer 2b: LLC = Logical Link Control Über der Hardware der Adapter arbeitet die Software des LLC-Treibers. LLC stellt Protokollkennungen bereit, mit denen sich Sender und Empfänger über das im Datenpaket enthaltene Protokoll verständigen.

168

Layer 3: Network

LLC SAPs Diese Protokollkennungen werden SAP genannt: Service Access Points. Die SAPs beschreiben Übergabepunkte in der Treiberhierarchie; solche Übergabepunkte (I/O Ports) und werden in höheren Schichten Ports oder Sockets genannt. LLC Data Flow Control LLC kann, muss aber nicht, mit der Funktion einer Datenfluss-Steuerung arbeiten. Wenn im lokalen Netz kein höheres Protokoll den Datenfluss gegenüber Störungen, Überlastungen, Verlusten etc. absichert, kann LLC entsprechend verwendet werden. Diese historisch aus SNA-Zeiten stammende Funktion hat sich in heutigen LANs fast vollständig auf höhere Schichten übertragen. Schon allein die Vernetzung von LANs zu WANs macht(e) erforderlich, dass Datenfluss-Steuerung von Ende-zu-Ende, also zwischen den Kommunikationspartnern hüben und drüben durchgeführt wird – und das heißt: über alle Router und Transitstrecken hinweg. Das aber kann LLC nicht leisten, weil es nur lokal arbeitet – es kann Router nicht überspringen.

8.6

Layer 3: Network Network Layer wird treffend mit »Vermittlungsschicht« übersetzt: hier findet das Routing statt. Die Bezeichnung »Netzwerk« für die dritte Schicht ist denkbar ungünstig, weil dies nahe legt, man bräuchte diese Schicht, um ein Netzwerk zu betreiben. Die Bezeichnung Internetworking wäre angemessener. Aus heutiger Sicht ist das irreführend; aus der Sicht der 70er Jahre ist das korrekt, da man damals als »Netzwerk« – salopp gesagt – einen Modemverbund von Rechnern am Telefonnetz verstand.

8.6.1

Modem Sharing – Gateways – Router Diese Rechner, die damals stark mit dem Betriebssystem Unix vertreten waren, übernahmen dann die Aufgabe, gewissermaßen in einer Form des Modem Sharings, die just entstehenden LANs an dieser Kommunikation teilhaben zu lassen. Nach einiger Zeit der Entwicklung entstanden aus diesen Gateways die heutigen Router.

8.6.2

Netzwerkadressen Da MAC-Adressen nur im jeweils lokalen Netzwerk (aus der Sicht des »Netzwerkes«:) hinter dem Router Gültigkeit haben, musste zur Adressierung ferner Rechner ein neuer Mechanismus eingeführt werden.

Kapitel 8 • Das OSI-Modell

169

Diese Aufgabe übernimmt das jeweilige Netzwerkprotokoll auf Schicht 3 – etwa IP oder IPX. Beide Protokolle arbeite(te)n historisch mit nur vier Byte langen Adressen. Das reicht heute im World Wide Web nicht mehr aus; entsprechend wird jetzt auf eine neue IP-Version mit 16 Byte langen Adressen gewechselt.

8.6.3

Router Exchange Protocols Die Router haben im »Netzwerk« die Aufgabe, die Verbindungen zwischen allen angeschlossenen Rechnern und Teilnetzen herzustellen und zu sichern. Dies geht nur durch die mehrfache Verfügbarkeit getrennter Verbindungen. Um in einem sog. vermaschten Netz sowohl den Regel- wie auch den Notbetrieb organisieren zu können, tauschen die Router regelmäßig ihr Wissen miteinander aus; dies fing historisch mit RIP (Routing Information Protocol) an und führte dann zu Protokollen wie BGP, [E-] IGRP, OSPF, NLSP. Diese neueren Protokolle erlauben ein hohes Maß an Verfügbarkeit und Ressourcennutzung. Das Meiste läuft hier zwar automatisch ab; gleichwohl ist eine Feinabstimmung der Routing-Protokolle eine durchaus anspruchsvolle und knifflige Angelegenheit.

8.6.4

Layer 3 – verbindungslos/ungesichert Die Kommunikation der Endgeräte über Layer 3, aber auch der Datenaustausch zwischen den Routern auf der Netzwerkschicht verläuft verbindungslos und ungesichert.

8.7

Layer 4: Transport Die Übersetzung von Transport Protocol zu Transportprotokoll ist zwar sprachlich eher langweilig, aber zutreffend, weil auf Schicht 4 aus Sicht des Betriebssystems der teilnehmende Rechner die meiste und maßgebliche Arbeit verrichtet . Ein Schicht-4-Protokoll verhält sich wie ein Transportspediteur, dem wir ein Paket übergeben, ohne uns unsererseits darum zu kümmern, welche Route das Paket durch das Network von Zwischenlagern und Endlagern läuft, bis es endlich zugestellt wird. Dem Nutzer gegenüber (in der Sprache der Tansportprotokolle tatsächlich User genannt) bleiben die näheren Vorgänge der Transportschicht und der darunterliegenden Schichten verborgen.

170

8.7.1

Layer 4: Transport

Layer 4 – verbindungsorientiert/abgesichert Die Transportprotokolle betreiben im Gegensatz zu den Protokollen der darunter liegenden Schichten vorwiegend eine verbindungsorientierte und abgesicherte Datenkommunikation.

8.7.2

Datenfluss-Steuerung Auf der Transportschicht findet bei Protokollen wie etwa TCP eine ziemlich aufwendige Datenfluss-Steuerung statt, die wesentlich folgende Aufgaben zu erfüllen hat: •

Vermeidung von Überlastung beim Empfänger (Annahmestau, Pufferüberlauf)

•

Aufteilung der zu übertragenden Datenmenge in kleinere Einheiten, sog. Pakete, wesentlich in Abhängigkeit von der Blockgröße (Frame Size) auf Layer 1 und Layer 2. – Nummerierung dieser Pakete zum Erreichen folgender Zwecke: – Prüfung beim Empfänger auf Vollständigkeit aller eingegangenen Daten. – Bestätigung des Erhalts durch den Empfänger gegenüber dem Sender. – Veranlassung einer wiederholten Übertragung bei Verlust von Daten.

Bei Transportprotokollen spielt Zeitsteuerung eine sehr wichtige Rolle, da das Erwarten von Daten und Quittungen an sog. Timer (Wartezeiten) gebunden ist.

8.7.3

Handshake/Verbindungsaufbau und -abbau Protokolle der Transportschicht »klopfen an«, sagen sich »Hallo« und teilen sich gegenseitig ihre Kommunikationsbereitschaft mit, bevor sie Daten senden bzw. austauschen. Deswegen nennt man sie auch »verbindungsorientiert.«

8.7.4

Quick And Dirty Da nicht jede Versendung auf der Transportschicht den Aufwand eines Verbindungsaufbaus erfordert (kurze Abfragen bei Name Servern beispielsweise) , und da dies bei manchen Vorgängen sogar unmöglich wäre (bei Rundsendungen/ Broadcasts), gibt es die Möglichkeit, alle Sicherung beiseite zu lassen und verbindungslos zu senden. Die beiden am weitesten verbeiteten Transportprotokolle haben darum »kleine Brüder«, die den Transport auch verbindungslos und ungesichert erledigen können: TCP (DoD) hat UDP zum Partner, und SPX (NetWare) hat PEP für diese Fälle (wird allerdings sehr selten benutzt).

Kapitel 8 • Das OSI-Modell

8.8

171

Layer 5: Session Sessions sind Sitzungen. Hier werden nicht Handshakes wie auf der Transportebene durchgeführt – hier sprechen die Betriebssysteme selber miteinander. Sitzungen auf dem Layer 5 sind Datenbeziehungen, die in aller Regeln ein Mindestmaß an Vertraulichkeit voraussetzen.

8.8.1

Login/Authentisierung Allgemein werden Login-Verfahren bzw. Benutzer-Authentisierungen der Schicht fünf zugeordnet; es gibt aber auch Fälle, bei denen es Sinn ergibt, dies der Schicht sieben zuzuordnen. Bekannte Session Protocols sind NetBIOS (Network Basic Input/Output System) aus der IBM/Microsoft-Welt sowie RPC (Remote Procedure Call) aus der UnixWelt (beides inzwischen wechselseitig adaptiert).

8.8.2

Zugriffsschlüssel Teilweise findet auf Schicht fünf der Austausch bzw. die Vergabe von Zugriffsschlüsseln statt, mit denen sich ein Anwender als bereits authentisiert kennzeichnen kann. Diese Funktion ist heute eher auf Schicht sieben zu finden, da sie allgemein eine Server-Funktion darstellt.

8.9

Layer 6: Presentation Die Altväter der Normierung (ISO, IEEE) hatten noch mit der Tatsache zu tun, dass sie eine allgemein kompatible Kommunikationstechnik zu entwerfen hatten unter der Bedingung, dass Dutzende von Herstellern mit vielen, vielen verschiedenen Rechnern und Betriebssystemen vertreten waren. Es war eine wahrlich heterogene Welt. Heute gibt es kaum noch etwas außer IBM, Microsoft, Apple, Unix und Intel. Es sind nur noch extrem wenige Prozessorplattformen im Einsatz, und Microsoft deckt den Markt zu 90% (oder mehr) ab. Unter diesen Bedingungen wird uns gar nicht mehr bewusst, was Kompatibilität im Einzelnen bedeutet.

8.9.1

Lo/Hi – LSB/MSB – Little/Big Endian Beispielsweise könnte man die acht Bits eines Bytes statt von rechts-nach-links genau so gut von links-nach-rechts lesen; mit verketteten Bytes ist das ählich. Es geht um das Problem der binären Darstellung logischer Einheiten.

172

Layer 7: Application

Die Begriffe hierfür sind: •

Low or High Bit/Byte (Hi-Lo)

•

Least or Most Significant Bit (LSB/MSB)

•

Little or Big Endian (wie LSB/MSB)

•

Canonical/Non-Canonical

In den 80er Jahren begann Novell, sein Betriebssystem auf dem Motorola-Prozessor 68000 zu programmieren – der aber »sah« die Bits genau anders herum als Intel-Prozessoren. Mit dem Vormarsch der Intel-Prozessoren stellte dann auch Novell um. Mit der Homogenisierung der PC-Hardware wurde der Presentation Layer in seiner Funktion als Hardware Abtraction Layer weitgehend überflüssig.

8.9.2

Zeichensatztabellen Geblieben ist die notwendige Anpassung zwischen Maschinen, die unterschiedliche Zeichensätze verwenden. Zur Erinnerung: Ein »Byte« ist nicht eigentlich definiert als eine Folge von acht Bits, sondern als ein Element aus einer Zeichensatztabelle. Die Notwendigkeit einer Umwandlung von einer in die andere Tabelle ist heute in der Client-Server-Technik praktisch ausgestorben; bei SNA-Terminal-Emulationen aber findet sie immer noch statt. Ein bekanntes Protokoll der Schicht sechs wird teilweise von X-Window (Unix) verwendet: XDR – External Data Representation. Die meisten Protokolle der Schicht sieben beinhalten heute klare Konventionen über die Deutung der Bits und Bytes.

8.10

Layer 7: Application Diese Bezeichnung ist ähnlich missverständlich wie die der Schicht 3: Auf Schicht sieben arbeiten nicht etwa die Applikationen, sondern hier ist die Schnittstelle von/zu den Applikationen. Man hätte diese Schicht auch gut Network Application Programming Interface bzw. N-API nennen können. Die Client-Server-Kommunikation verläuft auf dem Application Layer.

Kapitel 8 • Das OSI-Modell

173

Die beiden wichtigsten Client-Server-Protokolle, die heute im Einsatz sind, werden dieser Schicht zugeordnet: •

SMB – Server Message Block (Microsoft)

•

NCP – NetWare Core Protocol (Novell)

Aber auch einige bekannte Unix-Anwendungen sind hier anzusiedeln: •

FTP – File Transfer Protocol

•

TELNET – Teletype Network

•

NFS – Network File System

•

SNMP – Network Management Protocol

•

SMTP – Simple Mail Transfert Protocol

Die vertracktesten Netzwerkfehler spielen sich auf dem Layer 7 ab, weil hier oft Protokolle arbeiten, die nicht allgemein zugänglich bzw. nicht veröffentlicht sind.

8.11

Header, Trailer, Daten: SDU+PCI=PDU Protokollanalyse folgt immer einem Strukturprinzip der Datenkommunikation: Jedes Protokoll einer bestimmten Schicht kommuniziert mit dem entsprechenden Treiber des Kommunikationspartners über Steuerdaten, die PCI (Protocol Control Information) oder schlicht Header (Kopfteil, Vorspann) und Trailer (Anhang, Schlussteil) genannt werden. Gemeinsam mit der Datenmenge, welche die höhere Schicht zwecks Übertragung an die tiefere Schicht übergibt und die SDU (Service Data Unit) genannt wird, bildet die PCI die sog. PDU (Protocol Data Unit). Kurz gesagt: SDU+PCI=PDU. Protokollanalyse ist also die Auftrennung des Inhaltes eines Datenpaketes in die verschiedenen Protokoll-Header (PCIs) und Daten (SDUs), jeweils gemeinsam erscheinend als PDU. Protokollanalyse ist darüber hinaus das auf den Einzelfall angewendete Wissen und Verständnis um die Wechselwirkungen und Dialoge, die zwischen Kommunikationsgeräten sichtbar sind – oder sichtbar sein sollten, aber nicht da sind.

174

Header, Trailer, Daten: SDU+PCI=PDU

Abb. 8.1: Das Prinzip von PCI und PDU im OSI-Modell

Kapitel 9 Physical Layer 9.1 9.2 9.3 9.4 9.5

Vorbemerkung Physical Coding Die häufigsten Fehlerquellen in der Physik Das Auffinden von Fehlern in der Physik 8B/6T Code-Tabelle

176 176 182 188 202

176

9.1

Vorbemerkung

Vorbemerkung Der Glaube, man benötige Kabeltester, um Kabelfehler schnell und zuverlässig zu erkennen, führt völlig in die Irre. Der Autor hat über die gesamte berufliche Laufbahn keinen einzigen Kabeltester besessen, und alle Kabelfehler konnten schnell und zuverlässig erkannt werden – und zwar mittels LAN-Analysator schneller als mit dem Kabeltester. Wie das? Nun – defekte Pakete liefern immer Aufschluss über den Ort und die Art des Fehlers, und das in verblüffend aussagekräftiger Weise.

9.2

Physical Coding Ohne Kenntnis der verschiedenen Formen der physikalischen Bit-Codierung lassen sich viele Fehler bei Ethernet oder Token-Ring gar nicht oder nicht schnell genug erkennen.

9.2.1

Bit-Codierungen im Shared Media LAN Für das Shared Media LAN waren von einfachen Code-Formen zwei spezielle Verfahren abgeleitet worden, die bei Ethernet (10 Mbps) und Token-Ring (4/16 Mbps) verwendet wurden bzw. immer noch verwendet werden. Das Physical Coding ab 100 Mbps folgt heute anderen Mustern; hier soll das Prinzip an den zuerst eingeführten Code-Mustern erklärt werden.

Abb. 9.1: Formen der Bit-Codierung: 10 Mbps Ethernet (Manchester), 4/16 Mbps Token-Ring (Differential Manchester) und andere

Kapitel 9 • Physical Layer

9.2.2

177

Signal-Kodierung/binär Die Darstellung digitaler Daten (binary digit = bit) erfolgt durch Verwendung lediglich zweier elektrischer Zustände für logisch »0« und »1«. Binär-Kodierung ist typisch für Shared Media LAN (Ethernet mit 10 Mbps, Token-Ring mit 4/16 Mbps).

9.2.3

Signal-Kodierung/ternär Die Darstellung digitaler Daten erfolgt durch Verwendung dreier elektrischer Zustände für verschlüsselte Symbole, in denen ganze Gruppen von logisch »0« und »1« dargestellt werden. Ternär-Kodierung stellt quasi eine Datenkompression auf Code-Ebene dar. Ternär-Kodierung wird u.a. bei ISDN und Fast Ethernet verwendet.

9.2.4

Signal-Kodierung & Kabel Aus dem Verhältnis aus physikalischer Bitrate (baud rate) und verwendeter Codierung ergibt sich eine bestimmte Frequenz (und umgekehrt). Da die Komplementärübertragungen im Twisted-Pair-Leiter ihre Ein- und Abstrahlfestigkeit nur haben bei einem bestimmten Verhältnis von Frequenz zu Drill (Schlag/Meter), gehören bestimmte Codierungen zu bestimmten Kabeln (und umgekehrt). Verletzungen des Drills im TP-Kabel führen zu Fehlern in der Komplementärübertragung und daher zu Bit-Fehlern in den Daten. In der Folge stimmen die Prüfsummen der Pakete nicht mehr, die Pakete werden verworfen.

9.2.5

Takt-Rückgewinnung/Synchronisation Der Wechsel zwischen verschiedenen elektrischen Zuständen in einem vorgeschriebenen Takt entscheidet über die Lesbarkeit (Verständlichkeit) der Signale beim Empfänger. Ohne Synchronisation des Empfängers mit dem Takt des Absenders wären die Daten nicht lesbar: Synchronisation = Taktrückgewinnung = Einstellung auf den Signaltakt = Einstellung auf die Signalfrequenz Daher werden sog. Self Clocking Codes eingesetzt – Kodierungen, die den Wechsel zwischen den elektrischen Zuständen nicht allein zur Darstellung von »0« und »1« verwenden, sondern zugleich auch zur Erzeugung (Aufrechterhaltung) des Taktes durch Pegelwechsel, also durch regelmäßigen Wechsel im elektrischen Volt-Pegel.

178

Physical Coding

Die Code-Tabelle in Abbildung 9.1 zeigt, dass die schlichte und übersichtliche NRZ-Codierung die Bits »0« und »1« mit jeweils einem durchgehenden VoltPegel darstellt. Würden nun viele Einsen oder Nullen hintereinander folgen, wäre statt eines Wechselstromsignals nur noch ein Gleichstrom-Signal auf der Leitung – das genau dadurch streng genommen auch gar kein Signal mehr darstellt und von niemandem mehr sauber aufgenommen werden kann. Beispiel eines LAN-Broadcasts: Die Empfängeradresse bei Broadcasts wird mit 0xFFFFFFFFFFFF dargestellt bzw. mit 48 Bits in Folge mit dem binären Wert »1«. Über eine so lange Gleichstromzeit hätte jeder Empfänger längst den genauen zeitlichen Takt der Bits verloren, da es kein Unterscheidungsmerkmal zwischen den Bits mehr gibt: Wenn der Empfängerquarz nur geringfügig schneller taktet als der des Absenders, so wird er statt 48 Bits vielleicht 51 oder 67 Bits »erkennen«; taktet der Empfänger langsamer, wird er entsprechend weniger als die tatsächlichen 48 Bits »erkennen«.

9.2.6

Die gängigsten Binär-Kodierungen Die bekanntesten Binär-Kodierungen sind aus der Code-Tabelle in Abbildung 9.1 ersichtlich; die beiden letzten wurden für Ethernet und Token-Ring verwendet: Binary Physical Code

Shared Media LAN Topology

Manchester Code

10 Mbps Ethernet

Differential Manchester Code

4/16 Mbps Token-Ring

Tab. 9.1: Die ersten Physical Codings für Shared Media LAN

9.2.7

RZ – Return to Zero »0« wird durch einen niedrigen, »1« durch einen hohen Pegel dargestellt; zur Mitte des Zeittaktes kehrt der Pegel auf Null zurück, wodurch RZ self-clocking ist: Das Frequenzsignal ist immer gegeben durch den erzwungenen Pegelwechsel in der Bit-Mitte.

9.2.8

NRZ – No Return to Zero Grundsätzlich wie RZ; nur eben kehrt der Pegel nicht auf Null zurück. Dadurch fallen je Bit weniger Pegelwechsel an. Mit derselben Frequenz könnten damit doppelt so viele Bits dargestellt werden im Vergleich zu RZ – dafür aber ist NRW nicht taktfest, da bei langen Folgen von binär »0« oder »1« Gleichstrom vorliegt und damit der Empfänger unter Synchronisationsverlust leiden würde.

Kapitel 9 • Physical Layer

179

Die Adressierungen im LAN, insbesondere die Broadcast-Adressen (48 Bits auf »1«) ließen sich mit NRZ zwar noch senden, aber nicht mehr lesen, da die Empfänger vor dem letzten Bit einer solchen langen Gleichstromfolge längst den Takt verloren hätten. NRZ ist »taktlos«.

9.2.9

NRZ-L – No Return to Zero/Level »0« und »1« werden durch hohen bzw. niedrigen Pegel dargestellt (polare Kodierung).

9.2.10 NRZ-M – No Return to Zero/Mark »0« und »1« werden durch Beibehalten bzw. Wechsel des Pegels dargestellt (auch: Differential NRZ).

9.2.11 NRZ-S – No Return to Zero/Space Wie NRZ-M, nur umgekehrt: »0« wird durch Pegelwechsel dargestellt, »1« durch Fehlen desselben – daher auch NRZ-I genannt: No Return to Zero/Inverted.

9.2.12 Manchester Code: Ethernet – 10 Mbps Die Darstellung von »0« und »1« lässt sich beschreiben entweder mittels des Eingangspegels in der ersten Bit-Hälfte (hoch = »0«, niedrig = »1«) oder mittels der Richtung des Pegelwechsels in der Bit-Mitte (hoch-auf-tief = »0«; tief-auf-hoch = »1«). In der Mitte des Zeittaktes erfolgt immer ein Pegelwechsel, der dadurch auch als Taktgeber (Clock) bzw. als Frequenzsignal wirkt. Bei Ethernet werden 10 Mbps mit wechselnd 10 oder 20 MHz dargestellt, je nach Abfolge von Null und Eins bzw. je nach vorhandenem Pegelwechsel an der Grenze zwischen zwei Bits. Das bedeutet – bezogen auf die gegebene Leistungsfähigkeit der Übertragungstechnik – einen Leistungsverlust von 50 % gegenüber einem NRZ-Code, dafür aber Taktfestigkeit.

9.2.13 Differential Manchester: Token Ring – 4/16 Mbps Hier zählt nicht der absolute Volt-Pegel, sondern die Tatsache, ob an der BitGrenze überhaupt ein Pegelwechsel stattfindet (oder nicht): »0« wird durch Pegelwechsel zu Beginn des Zeittaktes (bzw. an der Grenze zwischen zwei Bits) dargestellt, »1« dagegen durch Ausbleiben desselben. In der Mitte des Zeittaktes erfolgt immer ein Pegelwechsel (Clock); somit ist dieser Code taktfest.

180

Physical Coding

Bei Token Ring werden 4 Mbps wechselnd mit 4 oder 8 MHz, 16 Mbps wechselnd mit 16 oder 32 MHz dargestellt, je nach Abfolge von Null und Eins bzw. je nach vorhandenem Pegelwechsel an der Grenze zwischen zwei Bits. Das bedeutet – bezogen auf die gegebene Leistungsfähigkeit der Übertragungstechnik – einen Leistungsverlust von 50 % gegenüber einem NRZ-Code, dafür aber Taktfestigkeit.

9.2.14 4B/5B: FDDI – 100 Mbps Jeweils fünf Taktzyklen (baud) kodieren 4 Bits. Anders gesagt: Statt der vier »echten« Bits werden fünf physikalische Bits gesendet. Man versuchte, so nah wie möglich an den (aus damaliger Sicht) verlustfreien NRZ-Code heranzukommen, bei dem das Verhältnis von Baud-Rate zu Bit-Rate 1:1 beträgt. Hier wurde mit 4B/5B ein Verhältnis von 4:5 bzw. 1:1,2 erreicht. Bei FDDI werden auf dem LWL 100 Mbps mit 125 MHz bzw. 125 Mbaud dargestellt. 4B/5B hat also nur 20% Leistungsverlust im Verhältnis der physikalischen Baud-Rate und der logischen Bit-Rate, während der alte Manchester-Code 50% der Frequenzkapazität für das Clocking-Signal zur Bit-Mitte gewissermaßen verschwendet. 4B/5B bedeutet: 4 Bit im Binär-Code werden umgewandelt in 5 Bit (Baud) im Binär-Code. (Spätere Codes wandeln binäre Bits in ternäre Signale um, etwa 8B/6T). Ein Byte mit 2 x 4 Bit wird daher durch 2 x 5 Bit (Baud) dargestellt; die 5-BitGruppen werden als »Symbole« bezeichnet. Diese Kodierungstechnik wird auch RLL (Run Length Limited) genannt, weil im Gegensatz zum NRZ lange Gleichstrom-Folgen zuverlässig ausgeschlossen werden: Der Zweck des Austauschs der 4-Bit-Gruppen in 5-Bit-Symbole liegt darin begründet, dass die Symbole keine langen Gleichstrom-Folgen mehr zulassen. Originale 4-Bit-Gruppe 0000 0001 0010 0011 0100 0101 0110 0111 Tab. 9.2: 4B/5B Code-Tabelle von FDDI

Resultierendes 5-Bit-Symbol

→ 11110 → 01001 → 10100 → 10101 → 01010 → 01011 → 01110 → 01111

Kapitel 9 • Physical Layer

Originale 4-Bit-Gruppe 1000 1001 1010 1011 1100 1101 1110 1111

181

Resultierendes 5-Bit-Symbol

→ 10010 → 10011 → 10110 → 10111 → 11010 → 11011 → 11100 → 11101

Tab. 9.2: 4B/5B Code-Tabelle von FDDI (Forts.)

Einige Symbole sind in 4B/5B reserviert bzw. verboten: Bezeichnung des Symbols

Bedeutung/Bemerkung

00000 – "Quiet"

das Medium ist »tot«/kein NAUN

11111 – "Idle"

das Medium ist (vermeintlich) »frei«

11000 – "J"

wird im Start Delimiter verwendet

10001 – "K"

wird im Start Delimiter verwendet

01101 – "T"

wird im End Delimiter verwendet

11001 – "S"

wird als »logische 1« für A/C verwendet

00111 – "R"

wird als »logische 0« für A/C verwendet

Tab. 9.3: Reservierte Symbole im 4B/5B Code von FDDI

9.2.15 8B/6T: Fast Ethernet – 100 Mbps Der 8B/6T-Code ersetzt acht binäre, logische Bits durch sechs ternäre, physikalische Code-Einheiten; diese 6T-Einheiten werden »Symbole« genannt. Während noch bei FDDI bei 100 Mbps mehr als 100 MHz/100 Mbaud auf LWL aufgewendet werden mussten, um die Bitrate zu erreichen, ist bei 8B/6T die Frequenz niedriger als die Bitrate: 8B/6T kann 100 Mbps bei einer Frequenz von 75 MHz darstellen. + = oberer Volt-Pegel 0 = mittlerer Volt-Pegel – = unterer Volt-Pegel

182

Die häufigsten Fehlerquellen in der Physik

8B hex

6T bin.

8B hex

6T bin.

8B hex

6T bin.

8B hex

6T bin.

00

+-00+-

40

+0+00-

80

+-+00-

C0

+-+0+-

01

0+-+-0

41

++00-0

81

++-0-0

C1

++-+-0

02

+-0+-0

42

+0+0-0

82

+-+0-0

C2

+-++-0

03

-0++-0

43

0++0-0

83

-++0-0

C3

-+++-0

Tab. 9.4: Ausschnitt aus der 8B/6T Code-Tabelle

9.2.16 8B/10B: Gigabit Ethernet – 1000 Mbps Gigabit Ethernet verwendet in der Variante 1000BaseLX/SX einen 8B/10B Code; dieser ist eine Weiterentwicklung des 4B/5B-Codes von FDDI.

9.3

Die häufigsten Fehlerquellen in der Physik Es gibt Fehler in der Physik, die mit der jeweiligen Bit-Codierung bzw. mit dem Physical Coding eng zusammen hängen, da es jeweils sehr typische Erkennungsmöglichkeiten in den verschiedenen LAN-Topologien gibt.

Abb. 9.2: Schema der wichtigsten Fehler im Physical Coding

In den folgenden Darstellungen steht »ETH« jeweils für »Ethernet« und »TOK« für »Token-Ring«.

Kapitel 9 • Physical Layer

9.3.1

183

Netzeingangsstrom: Network BIAS Als Netzeingangsstrom wird der Volt-Pegel bezeichnet, mit dem ein elektrisches Signal anfangs auf das Medium gebracht wird. Fehler

Zu Beginn der Signalisierung beim Sender wird vom vorgeschriebenen Pegelwert zu sehr und zu lange abgewichen bzw. der vorgeschriebene Pegelwert wird nicht sofort korrekt erreicht. Dies führt nicht nur ggf. zu einer Verfälschung der Bits, sondern auch zu elektrischen Störungen bei(m) Empfänger(n). Dieser Fehler war in der Anfangszeit der LANs ein Problem; bei heutigen Bauteilen tritt dieser Fehler selten auf. Unerfreuliche Auswirkungen konnte dieser Fehler auf Koax-Kabeln haben, da sämtliche angeschlossenen Adapter betroffen sein konnten.

Kabel

Dieser Fehler tritt theoretisch unabhängig vom gewählten Kabel auf, ist aber historisch praktisch nur bei Koax-Netzen (Ethernet) zu suchen bzw. nur dort von größerem Belang.

Ursache(n)

Defekte Media Access Unit (MAU) bzw. defekter Transceiver (TxRx)

Abhilfe(n)

Die defekten Geräte müssen ausgetauscht werden.

Meldung(en)

ETH: CRC Error, Alignment Error TOK: CRC Error, Line Error, Burst Error

Tab. 9.5: Fehlercharakteristik bei Network BIAS

9.3.2

Phasenverschiebungen/Jitter Der Begriff »Jitter« steht sehr allgemein für Signalverzerrungen, sei es physikalisch mit Bezug auf die elektrische Charakteristik (so hier), sei es logisch mit Bezug auf das Zeitverhalten, wenn die Laufzeiten von Nachrichten durch ein Netz stark schwanken (so werden Laufzeitschwankungen bei Voice-over-IP als »Jitter« bezeichnet). Fehler

Synchronisationsverlust beim Empfänger und in der Folge ein Versatz des vermeintlich empfangenen Signals im Verhältnis zum tatsächlichen Signal. Beim (Differential) Manchester Code (Ethernet/Token-Ring) bedeutet dies, dass der Empfänger wegen fehlender Eindeutigkeit des Pegelwechsels (zu flache Flanke) bzw. wegen zu langsamen Kurvenverlaufs den Pegelwechsel bzw. das Taktsignal nicht mehr rechtzeitig als solches erkennt, was eine Verschiebung in der Bit-Aufnahme um eine Halb-Bit-Zeit bewirkt.

Tab. 9.6: Fehlercharakteristik bei Jitter bzw. Dämpfung

184

Die häufigsten Fehlerquellen in der Physik

Dieser Fehler tritt auf, wenn die angestrebte, ursprünglich beim Absender vorhandene »knackige« Rechteck-Kurve des Signals (Symbols) so weit abgeflacht ist, dass der A/D-Wandler (Analog-zuDigital-Wandler) des Empfängers die Entscheidung »Pegelwechsel ja/ nein« bzw. die Entscheidung »Bit=0/1« nicht mehr rechtzeitig treffen kann, bevor das Zeitfenster hierzu durchlaufen ist. Hierdurch entsteht subjektiv beim Empfänger der Eindruck einer Phasenverschiebung, also eines Versatzes des Signaltaktes, da sich der erwartete Pegelwechsel scheinbar zeitlich nach hinten verschiebt bzw. verschoben hat. Eine Sicht auf das Signal mit einem analogen Oszilliskop würde keinen Hinweis auf einen solchen Signalversatz zeigen – im Gegenteil, die Schwingungen wären immer noch im Takt der Frequenz. Es würde dagegen aber deutlich, dass die vorgeschriebene Amplitude (Signalstärke) schon lange nicht mehr erreicht bzw. unterschritten wird. Dieses Phänomen führt beim A/D-Wandler letztlich zu der physikalisch irrigen, logisch aber korrekten Annahme einer Phasenverschiebung. Kabel

Alle Kabeltypen: Koax, TP, LWL

Ursache(n)

Ursache kann alles sein, was die Rechteck-Charakteristik des Signals (Symbols) verfälschen oder schwächen kann. Allgemein ist die Ursache zumeist in Dämpfung zu suchen, die durch Kabelüberlängen entsteht: Mehr als 500 m bei dickem Koax (Yellow Cable) bzw. 10Base5, mehr als 185 m bei dünnem Koax (Thin Wire/Cheapernet) bzw. 10Base2, mehr als 100 Meter bei Twisted Pair (Cat-n). Bei alter Koax-Verkabelung kann auch eine zu große Zahl von T-Stücken (Anschluss-Stücken) und EAD-Dosen zu erhöhter Dämpfung und Signalabschwächung führen. Bei TP-Verkabelung kann ein Versagen der Komplementärübertragung bzw. ein Nahnebensprechen mehrerer Ader-Paare dafür sorgen, dass die vorgeschriebene Signalcharakteristik verfälscht wird – dann aber kann sowohl eine Verstärkung wie auch eine Abschwächung der Volt-Pegel die Folge sein, je nach zufälliger Überlagerung von PlusPlus, Plus-Minus oder Minus-Minus. Ungeschirmte TP-Kabel leiden hieran vorrangig, da bei großen Kabelbündeln die Gefahr des Übersprechens besonders groß ist. Geschirmte TP-Kabel können Signalverfälschungen erleiden, wenn der Folienschirm (der das Signal ja schützen soll) insbesondere durch falsche oder fehlende Erdung induktiv Spannung aufnimmt/Kapazität aufbaut und dadurch bedingt Ausgleichsströme transportiert. Auch Störstrahlungen, die auf Kabel und Signal einwirken, können eine Ursache sein; dann aber kämen ggf. noch andere Signalcharakteristiken und andere Auffälligkeiten hinzu.

Tab. 9.6: Fehlercharakteristik bei Jitter bzw. Dämpfung

Kapitel 9 • Physical Layer

185

Abhilfe(n)

Die Kabel dürfen nicht länger sein als vorgeschrieben; Repeater, Bridges und Switches müssen so im Netz angeordnet sein, dass keine Kabelüberlängen (irrtümlich) verlegt werden. Allgemein ist diese Fehlerart im LAN seit der weitgehend überall vollzogenen Migration von Koax zu TP sehr selten geworden.

Meldung(en)

ETH: CRC Error, Alignment Error. TOK: CRC Error, Line Error; seltener auch: Burst Error, Beacon

Tab. 9.6: Fehlercharakteristik bei Jitter bzw. Dämpfung

9.3.3

Abfallzeit: Fall Time Die Fehler-Charakteristik, die sich aus zu flachem Kurvenverlauf ergibt, wurde bereits unter Punkt 9.3.2 ausführlich behandelt; das Merkmal der Fall Time dient im Grunde nur der Beschreibung eines Elements dieser Charakteristik. Fehler

Zu viel Zeit verstreicht beim Pegelwechsel, die Flanke ist nicht steil genug.

Kabel

Alle Kabeltypen: Koax, TP, LWL

Ursache(n)

Vorrangig zu hohe Dämpfung, in aller Regel bedingt durch zu lange Kabelwege.

Abhilfe(n)

Kabeltypen und Kabellängen überprüfen, ggf. Kabel austauschen, ggf. Repeater einsetzen.

Meldung(en)

ETH: CRC Error, Alignment Error. TOK: CRC Error, Line Error; seltener auch: Burst Error, Beacon

Tab. 9.7: Fehlercharakteristik der Fall Time/Abfallzeit beim Pegelwechsel

9.3.4

Bit-Rate: bit rate Auch hier handelt es sich lediglich um ein statistisches Merkmal bzw. um eine Erscheinungsform, deren Fehlercharakteristik bereits unter Punkt 9.3.2 hinreichend dargestellt wurde. Bei Token-Ring kommt jedoch noch das gesonderte Szenario eines Ring-SpeedFehlers hinzu: Fehler

Gleichstromanteil (D.C. Component) und Wechselstromanteil (A.C. Component) stimmen nicht; die Frequenz weicht vom vorgeschriebenen Maß ab. In aller Regel ist ein solches Ereignis subjektiv für den Empfänger auf wenige Bit-Längen, oft nur Halb-Bit-Zeiten beschränkt und auf Dämpfung zurückzuführen (siehe »Jitter«).

Tab. 9.8: Fehlercharakteristik bei Bit-Rate und Ring Speed

186

Die häufigsten Fehlerquellen in der Physik

Bei Token-Ring jedoch kann tatsächlich bei einem Adapter (bezogen auf den aktuellen Ring) die falsche Bit-Rate (Ring Speed) eingestellt sein. Dies führt allgemein zu einer Beacon-Phase auf dem Ring. Wenn der falsch eingestellte Adapter nicht sofort den Ring wieder verlässt, bricht der ganze Ring zusammen (so geschehen bei den ganz alten 4Mbps-Adaptern von IBM aus den 80er Jahren). Kabel

Alle Kabel-Typen: Koax, TP, LWL

Ursache(n)

Phasenverschiebungen (Jitter). Nur bei Token-Ring: falscher Ring Speed zwischen Ring und neu eintretendem Adapter.

Abhilfe(n)

Für Dämpungsphänomene: siehe »Jitter«. Token-Ring Ring Speed: Entweder muss am Adapter der Ring Speed richtig eingestellt werden, oder der Adapter muss ausgetauscht werden, weil seine Fähigkeit zum automatischen Erkennen des Ring Speed bzw. zum entsprechend richtigen Einstellen auf diesen Ring Speed verloren ging.

Meldung(en)

ETH, TOK: siehe »Jitter«. TOK (bei Ring Speed Fehler): Frequency Error; Burst Error; Beacon.

Tab. 9.8: Fehlercharakteristik bei Bit-Rate und Ring Speed (Forts.)

9.3.5

Einwirkende Störstrahlungen Es wurde bereits unter Punkt 9.3.2 auf Signalfehler hingewiesen, die durch Nahnebensprechen bzw. Übersprechen entstehen können. Diese Art von Störstrahlung ist hier nicht gemeint; dieser Absatz beschreibt Einwirkungen von externen Strahlungsquellen. Fehler

Strahlenquellen in der Umgebung verfälschen die Signale. In der Folge ereignen sich Frequenz- und Bit-Fehler.

Kabel

Koax, TP. Es muss bemerkt werden, dass die Neigung, induktiv Spannung aufzunehmen, beim Koax-Kabel ungleich größer ist als beim TP-Kabel. Bei der Koax-Verkabelung, die typischerweise oft horizontal im Kabelkanal unter der Fensterbank lang lief, reichte schon eine außen vorbei fahrende Straßenbahn mit einem Knistern in der Oberleitung, um massiv die Übertragungen auf dem Koax-Kabel zu stören. TP-Kabel sind hier wesentlich unempfindlicher. Jedoch kann eine falsche Erdung geschirmter TP-Kabel zu diesem sonst praktisch nicht vorkommenden Fehler führen.

Tab. 9.9: Fehlercharakteristik bei einwirkender Störstrahlung

Kapitel 9 • Physical Layer

187

Der prinzipielle Unterschied beider Kabelarten führt zu der verschiedenen Anfälligkeit gegenüber Einstrahlungen: Das Koax-Kabel ist ein sog. asymmetrisches Kabel, das TP-Kabel ist ein sog. symmetrisches Kabel. Seele und Außenleiter verteilen sich beim Koax-Kabel nicht symmetrisch um den gemeinsamen Mittelpunkt, der allein von der Seele gebildet wird. Bei TP winden sich die gedrillten Adern gleichmäßig um einen gemeinsamen Mittelpunkt. Dies führt dazu, dass bei TP beide Adern gleichmäßig von Störstrahlungen betroffen werden, während beim Koax-Kabel ja das erklärte Ziel war, mit dem Außenleiter einen Farraday’schen Käfig um den Innenleiter zu bilden. Dadurch kommt es zu ungleichen Erscheinungen zwischen Innenund Außenleiter, wenn letzterer induktiv Spannung aufnimmt. Ursache(n)

Die Ursachen der Strahlung sind in äußeren Quellen zu suchen; die Empfindlichkeit der Kabel ist entweder in unzureichender Verkabelung (Koax statt TP) oder fehlerhafter Verkabelung (falsche Erdung bei geschirmtem TP) zu suchen.

Abhilfe(n)

Die Kabel entsprechend austauschen, die Strahlungsquelle abstellen.

Meldung(en)

ETH: CRC Error, Alignment Error, ggf. Collision TOK: CRC Error, Line Error, Burst Error, ggf. Beacon

Tab. 9.9: Fehlercharakteristik bei einwirkender Störstrahlung (Forts.)

9.3.6

Relaisschaltungen: Token-Ring Hier von einem »Fehler« zu sprechen, wäre falsch. Dem Laien erscheint das Ereignis jedoch als Fehler, da der Analyzer es so anzeigt. Fehler allerdings können auftreten, wenn Token-Ring-Adapter oder Ringleitungsverteiler nicht korrekt reagieren. Fehler

Ein Relais wird am Ringleitungsverteiler (mechanisch oder elektronisch) geöffnet oder geschlossen. Die hierdurch bewirkte Unterbrechung des Frequenzsignals oder gar eines gerade durchlaufenden Paketes wird vom nachfolgenden Adapter erkannt und mit Fehlermeldung an den Ring Error Monitor (REM) bekannt gemacht. Die unmittelbare Wahrnehmung des nachfolgenden Adapters ist ein »Riss« im Signalstrom (Burst Error), der bei längerem Anhalten zum Ausfall des Ringes führen kann (Beacon). Theoretisch müsste es so sein, dass nur der unmittelbar nachfolgende Adapter diesen Fehler »sieht«, da er gehalten ist, die Löcher im Signalstrom zu stopfen. Betrifft dies einen gerade durchlaufenden Frame oder ein durchlaufendes Token (und das ist fast immer der Fall), so wird das Loch im Frame mit Stopf-Bits aufgefüllt; am Ende wird der Frame mit dem »Error Recognized«-Bit abgestempelt (gilt nicht für Token).

Tab. 9.10: Fehlercharakteristik bei Relais-Schaltungen im Token-Ring

188

Das Auffinden von Fehlern in der Physik

Tatsächlich aber ist überwiegend bei solchen Relais-Schaltungen zu beobachten, dass mehrere Adapter melden, das Szenario beobachtet zu haben. Dies ist streng genommen irregulär, hängt aber von der Bauweise und vom Alter der Komponenten ab. Aus Erfahrung lässt sich sagen: Wenn am 8-Port-Verteiler etwa 2-4 Adapter die Schaltung melden, kann das hingenommen werden. Wenn aber 5-8 Adapter Meldungen an den Ring Error Monitor (REM) schicken, oder wenn bei einer elekronischen Verteilereinheit, etwa einer LAM mit 24 Ports, alle Adapter das Ereignis melden, so ist ganz sicher davon auszugehen, dass der Verteiler defekt ist, da er die Schaltung auf alle Ports durchgibt bzw. durchschlagen lässt. Dies hat seine Ursache dann entweder in der Logik, die Aussetzer an allen Ports erzwingt, oder es liegt an mangelnder galvanischer Trennung der Ports und an einem Durchschlagen von Überspannungen, die bei Schaltungen kurzfristig auftreten. Etwa in 1997/98 brachte IBM eine Generation von LAMs heraus, die massiv unter diesem Fehler litten. Dies scheint inzwischen behoben. Ansonsten kann das Auftreten von Meldungen mehrerer Adapter bedeuten, dass diese zu träge sind, wenn es darum geht, Löcher in der Signalkodierung zu stopfen, was dazu führt, dass nachfolgende Adapter auch noch etwas zu tun haben. Hier spielt in der Beurteilung des Fehlers eine Rolle, ob die Fehler meldenden Adapter physikalisch unmittelbar hintereinander in Folge am Verteiler sitzen (das wäre dann im weitesten Sinne noch hinnehmbar) oder eben nicht – das wäre dann wieder ein Hinweis auf Fehler am Verteiler. Kabel

TP (IBM Typ 1, Cat-n)

Ursache(n)

Defekter Ringleitungsverteiler, defekte (träge) Adapter.

Abhilfe(n)

Austausch von Verteiler und/oder Adapter.

Meldung(en)

TOK: Burst Error, Token Error, Line Error.

Tab. 9.10: Fehlercharakteristik bei Relais-Schaltungen im Token-Ring (Forts.)

9.4

Das Auffinden von Fehlern in der Physik Zunächst einmal muss festgehalten werden, dass die Darstellungen über Fehler im Physical Layer im Analyzer je LAN-Topologie deutlich anders ausfallen. Während bei Ethernet nur wenige Zähler ausreichen müssen, um auf bestimmte Fehler in der Netzwerkphysik zu schließen, stellt sich Token-Ring als äußerst »geschwätzige« Technik heraus, die über erhebliche Fähigkeiten zur eigenen Fehlererkennung verfügt. Und doch gilt für beide zugleich, dass mit den Mitteln des LAN-Analysators in aller Regel schnell und zuverlässig Fehler im Physical Layer gefunden werden können – ungeachtet der unterschiedlichen Fähigkeiten zur Eigendiagnose.

Kapitel 9 • Physical Layer

189

Abb. 9.3: Typische Fehleranzeige bei Ethernet (LANdecoder32)

Abb. 9.4: Typische Fehleranzeige bei Token-Ring (LANdecoder32)

9.4.1

Kabeltester Viele glauben, dass Kabeltester dazu gedacht seien, Kabelfehler zu finden. Das ist ein Irrtum! Wie der Name schon sagt: Kabeltester sind dazu da, Kabel zu testen; dass bedeutet aber noch lange nicht, dass sie geeignet wären, Kabelfehler zu finden – jedenfalls nicht in einer angemessenen Art, nämlich möglichst schnell und möglichst ohne großen Aufwand. In den vorigen Abschnitten wurde bereits für eine Vielzahl von Standardereignissen bzw. Standardfehlern nachgewiesen, dass sie mit jedem Messgerät gut erkannt werden können, das die für die jeweilige LAN-Topologie typischen Fehler anzeigen kann. Dies könnten sowohl ein moderner Kabeltester bzw. LANTester sein wie auch ein Protokoll-Analysator (der vom Autor in allen Fällen vorgezogen wird).

190

Das Auffinden von Fehlern in der Physik

Die folgenden Abschnitte weisen nach, dass mit dem LAN-Analysator (Protokoll-Analysator) wesentlich schneller und besser defekte Kabel oder Verteiler (Repeater, Bridges, Switches) aufgespürt werden können.

9.4.2

Twisted-Pair-Verkabelungen Wenn Datenpakete fehlerhafte Stellen in Kabel/Stecker/Buchse durchlaufen, werden sie verfälscht. •

Entweder kann der Analyzer die verfälschten Pakete sehen (im selben physikalischen Segment, in dem allenfalls Repeater oder Ringverteilungsleiter eingeschaltet sind),

•

oder er kann sie nicht sehen (weil Bridges/Switches/Router defekte Pakete verwerfen).

Wenn der Analyzer defekte Pakete erkennt, ist leicht zu erkennen, woher sie stammen (mittels der Absenderkennung) und welche Segmente bzw. Kabel durchlaufen wurden (mittels Dokumentation). •

Sind defekte Pakete nur von einem Absender zu finden, so kann nur dessen LAN-Adapter, dessen Anschlusskabel zum Verteiler (Repeater) samt Stecker und/oder die Eingangsbuchse dieses Verteilers defekt sein.

•

Sind defekte Pakete von mehreren Absendern zu finden, so gibt es zwei Möglichkeiten: Entweder sind diese Absender über das gesamte Netz weit verstreut; dann wären diese Fehler entweder rein zufällig (etwa Ethernet-Kollisionen), oder es gibt eben überall defekte Geräte, etwa deswegen, weil überall Geräte derselben Baureihe eingesetzt wurden und diese Baureihe fehlerhaft ist. Oder aber diese Absender defekter Pakete siedeln alle am selben Verteiler; dann ist entweder dieser Verteiler defekt (sei es an den Eingangsbuchsen, sei es am Ausgangs-Port), oder die UpLink-Leitung zum nächst höheren Verteiler in der Kaskadierung ist defekt, oder aber dieser zweite Verteiler hat einen defekten Eingangs-Port. Oder aber diese Absender defekter Pakete siedeln an mehreren Verteilern, die aber sämtlich in irgendeiner Kaskadierungsstufe an ein und demselben Backbone-Verteiler hängen: Dann ist dieser defekt. Wenn der Analyzer aber gar keine defekten Pakete »sieht«, weil sie zwischenzeitlich von einer Bridge/einem Switch/einem Router verworfen wurden, so sind doch bei einer Analyse der Data-Flow-Control-Abläufe Zeitüberschreitungen und ggf. Übertragungswiederholungen erkennbar (ReTransmissions, ReTx) – was wiederum auf das nämliche Ereignis rückschließen lässt sowie mittels der Absenderkennnungen auf den Ort des Fehlers.

Kapitel 9 • Physical Layer

191

Alles das lässt sich in einem Shared-Media-Ethernet (mit Repeatern) und einem Shared-Media-Token-Ring (mit Ringleitungsverteilern) schnell und zuverlässig eingrenzen – viel besser als mit dem Kabeltester. Kabeltester leiden zudem – je nach Art der Messung – unter einem immensen messtechnischen Problem: Sie verändern das zu messende System und machen die Messung dadurch latent ungültig. Was bedeutet das? Um ein Kabel nach allen Regeln der Kunst und mit allen Möglichkeiten des Kabeltesters durchzumessen, muss das Kabel aus dem Betrieb genommen werden: Es wird auf beiden Seiten aus den Buchsen der Verteiler genommen; auf ein Ende wird der Kabeltester gesteckt, der sodann Testsignale sendet und auf die Reflexionen »hört«; damit es diese Reflexionen aber gibt, muss das sog. ferne Ende offen sein. Es ist unbestreitbar, dass viele Kabelfehler auf diese Weise gefunden werden können. Und doch hat dieses Verfahren ein paar ganz massive Schwächen: •

Es gibt Fehler, die nicht sichtbar werden, wenn das Kabel datentechnisch in Ruhe ist, wenn also keine Datenpakete darüber fließen. Dann ist der KabelTester »blind«.

•

Dies ist insbesondere dann der Fall, wenn Erdungsfehler vorliegen und sich durch den laufenden Datenverkehr langsam induktive Kapazitäten aufbauen und schließlich Ausgleichsströme über den Folienschirm abgeleitet werden, was wiederum die durchlaufenden Daten beeinflussen kann. Zwar ist es möglich, dass ein Kabeltester solche Fehler auch erkennen kann, wenn das sog. ferne Ende im Verteiler eingesteckt bleibt; da aber wenigstens das sog. nahe Ende aus seinem Verteiler oder seinem LAN-Adapter entfernt werden musste, um den Kabeltester anzuschließen, ist das elektrische System so signifikant verändert, dass nicht mehr dasselbe System gegeben ist, unter dem der Fehler eigentlich auftritt. Ein LAN-Analysator kann zwar nicht exakt sagen: »Hier ist ein Erdungsfehler.« Aber der LAN-Analysator zeigt exakt den Ort bzw. den betroffenen Anschluss, und oft ist sogar doch der genaue Fehlertyp durch ein paar wenige, einfache Rückschlüsse erkennbar.

•

Messungen mit dem Kabeltester lassen sich oft nur schwerlich tagsüber durchführen, weil in die Arbeit der Anwender doch zu stark eingegriffen würde. Deswegen finden solche Arbeiten dann oft nachts statt. Dann aber potenziert sich der systematische Messmangel: Dann ist erst recht nicht mehr die Umgebung anzutreffen, die für den Fehler typisch ist. Und durchlaufender Datenverkehr gehört nun einmal zur »Umgebung« bzw. zu den Bedingungen, unter denen der Fehler auftritt. Ein LAN-Analysator aber kann über Tag und über Nacht ständig mitlaufen, ohne Beeinträchtigung der Anwender und ihrer Arbeit; er hat einen sehr viel

192

Das Auffinden von Fehlern in der Physik

weiteren Horizont, weil er Aussagen zulässt über weit mehr Anwender und Anschlüsse, als dies ein Kabeltester je könnte; und er kann im Zweifel die Messdaten über lange Zeit speichern, um sie in schwierigen Fällen für eine spätere, zusätzliche Auswertung zu bewahren. •

Es kann sein, dass der Kabeltester ein Kabel als »defekt« bzw. »unbrauchbar« einstuft, das gleichwohl die Daten fehlerfrei überträgt. Dies kann geschehen, wenn die Toleranz der jeweiligen Empfänger so gut ist, dass erste Deformationen dem einwandfreien Lesen der Daten immer noch nicht schaden können. Nun spricht zwar nichts dagegen, ein solcherart unter Verdacht geratenes Kabel in jedem Falle auszutauschen. Aber es ist gefährlich, diesem Befund in missverständlicher Weise zu vertrauen, und zwar so, dass man glaubt, man habe den Fehler bzw. seine Ursache gefunden und beseitigt. Spätestens dann, wenn sich am nächsten Morgen der altbekannte Fehler wieder einstellt, wird man bemerken, dass die mittels Kabeltester erkannten Mängel zwar da waren, aber mit dem aktuellen Fehler nichts zu tun hatten. Um hier das richtige Ursache-Wirkung-Verhältnis bzw. die tatsächlichen Wechselwirkungen zutreffend zu erkennen, muss zwingend mit einem LANAnalysator gearbeitet werden.

Alles das zeigt: Der LAN-Analysator ist zum Auffinden von Fehlern in der Physik unverzichtbar und dem Kabeltester haushoch überlegen.

9.4.3

Koax-Kabel Einen eindeutigen Vorteil hat der Kabeltester allein bei Koax-Verkabelung – aber auch dann gilt dieser Vorteil nur unter der Bedingung, dass über die Reihenfolge der angeschlossenen Ethernet-Stationen sowie über ihre Abstände am KoaxKabel keine hinreichende Dokumentation vorliegt. Liegt die Dokumentation sehr wohl vor, ist auch hier der LAN-Analysator an Effizienz deutlich überlegen, weil der Fehler schneller und während des laufenden Betriebes eingekreist werden kann, und zwar bis auf das genaue Teilstück hinunter (zwischen zwei Adapteranschlüssen, etwa T-Stücken oder Vampir-Taps). Im Einzelfall kann es sogar sein, dass die Bestimmung des Fehlerorts (etwa eines Kurzschlusses oder Wackelkontakts) mittels LAN-Analysator genauer ist, (a) weil wegen der längeren Messdauer über Tage und der größeren Zahl der Fehlerereignisse die statistische Aussagekraft wächst, (b) weil Kabeltester für ihre Tests bestimmte Mindestlängen des Kabels voraussetzen, die nicht immer gegeben sind.

Kapitel 9 • Physical Layer

193

Allerdings darf gesagt werden: Der beste Schutz vor Fehlern bei Koax-Kabeln ist ihre ersatzlose Abschaffung! Niemand sollte mehr mit diesem fehleranfälligen Medium arbeiten. Der Autor hat selten Koax-Verkabelungen gesehen, die einwandfrei geerdet waren – ein Mangel, der äußerstenfalls bei Blitzeinschlag nicht nur Dutzende von Geräten zerstören, sondern sogar Gesundheit und Leben von Menschen gefährden kann.

9.4.4

Token-Ring mit IBM Typ-1 Kabel Wie im Kapitel über Token-Ring-Analyse noch weiter ausgeführt werden wird, ist der Einsatz von Kabeltestern bei Token-Ring-LANs, die mittels Typ-1-Kabeln und Ringleitungsverteilern arbeiten (also ohne TokenSwitch), geradzu skurril zu nennen. Bei Token-Ring überwacht jeder Adapter die durchlaufenden Pakete sowie die Aktivitäten des im Ring stromaufwärts liegenden Nachbarn. Werden Fehler festgestellt, sendet jeder Adapter eindeutige Fehlermeldungen in den Ring, die – von nur ganz seltenen Ausnahmen abgesehen – einwandfreien Aufschluss geben über •

die Art des Fehlers,

•

den Ort des Fehlers (zwischen welchen zwei Adaptern),

•

die Häufigkeit des Fehlers.

Außerdem werden defekte Adapter, oder Adapter mit defekten Kabelanschlüssen, mit fast vollständiger Sicherheit vom Ring getrennt, wenn Fehler ihrer Art oder ihrer Häufigkeit nach den gesamten Ring gefährden. Kabeltester haben es schwer, aus den Fehler- bzw. Ereignismeldungen der TokenRing-Adapter immer die richtigen Schlüsse zu ziehen; vor allem aber haben sie wegen ihrer kleinen Displays ein Darstellungsproblem. Wer in einem Ring, der als fehleranfällig bekannt ist, einen LAN-Analysator anschließt und einen Filter auf die sog. MAC Frames setzt (damit ist das »Geplapper« der Token-Ring-Adapter untereinander gemeint), wird zuverlässig jedem Fehler auf die Spur kommen. So genau und aussagesicher kann kein Kabeltester arbeiten. Einschränkend muss jedoch gesagt werden, dass bei sog. Beacon (bei schweren Hardware-Störungen) ein Analyzer allein nicht immer ausreicht; es kann in extremen Fällen nötig sein, an verschiedenen Punkten mehrere Analyzer einzukoppeln, da das Beacon-Ereignis an verschiedenen Stellen des Ringes unterschiedlich »aussieht«. Erst verschiedene »Sichtweisen« können im Vergleich dann die Sicherheit einer genauen Diagnose geben.

194

Das Auffinden von Fehlern in der Physik

Die beste Software, die zur Überwachung der Token-Ring-Physik aus Sicht des Verfassers am Markt verfügbar ist, ist ein altes DOS-Produkt: TokenVision (Triticom). Das Auffinden von Fehlern im Ring ist hier wirklich eine Sache von Sekunden. Es wurde schon an anderer Stelle beschrieben, dass DOS-Analyzer (zwar nicht neu gekauft, aber) durchaus nicht »entsorgt« zu werden brauchen, wenn sie denn einmal da sind: Bei Shared-Media-LANs können sie bis zum vollständigen Wechsel zu Switched LANs immer noch wertvolle Dienste leisten.

9.4.5

Netzwerk-Management mit SNMP+RMON SNMP = Simple Network Management Protocol RMON = Remote (Network) Monitoring Ansonsten sollte das Netzwerk-Mangement via SNMP automatisch vor Schwellwert-Überschreitungen an sämtlichen Verteiler-Ports im gesamten Netzwerk warnen. Der Stand der Technik erlaubt gegenüber physikalischen Fehlern inzwischen ein fast vollständig automatisiertes Verfahren. Übersteigt beispielsweise der Wert defekter Pakete den hierfür gesetzten Schwellwert von 5% (Ethernet wegen der Kollisionen), so kann per SNMP automatisch Alarm an die zentrale SNMP-Console erfolgen. Auf dieser SNMP-Console sollte sofort durch Wechsel der Farbe »grün« zu »rot« sichtbar werden, wenn an einem Verteiler ein Port physikalische Fehler oder sonstwelche Auffälligkeiten meldet. Ein Mausklick auf den Port in der Grafik sollte sodann die genauen Statistiken und Meldungen zeigen. Zu SNMP kann noch RMON hinzukommen, was die Chance gibt, per Fernzugriff Pakete gezielt einzulesen und auszuwerten, um weiteren Auschluss zu erreichen. Die Überwachung mittels SNMP und ggf. RMON leidet jedoch daran, dass damit die Zuverlässigkeit genau des Netzes vorausgesetzt wird, dessen Physik gestört ist – das ist ein Widerspruch in sich. Die einzige Behebung dieses Mangels besteht in einem sog. Out Of Band Monitoring, was besagt, dass der Zugriff auf den SNMP-Agenten nicht über dasselbe Medium bzw. Netz erfolgt, das überwacht werden soll. Dies kann erreicht werden mit einem Zugriff auf die aktiven Komponenten und ihre SNMP-Agenten via Wählleitung und Modem. Da dieses Szenario aber für das lokale Monitoring auf dem örtlichen Campus sehr abwegig sein dürfte, muss SNMP-Überwachung als zwar unverzichtbar, aber eingeschränkt aussagekräftig bzw. eingeschränkt zuverlässig eingestuft werden.

Kapitel 9 • Physical Layer

195

Am Ende hilft eben doch nur, sich mit dem Analyzer unmittelbar in das betroffene Segment zu klinken bzw. sich an den Mirror-Port des betroffenen Switches zu hängen.

9.4.6

Eingrenzungen mittels Verkehrstabellen Einzeltabellen vs. Dialogtabellen Wenn der LAN-Analyzer eingesetzt wird, um Fehler in der Physik zu offenbaren, so sollte der Analyzer in der Lage sein, sog. »Verkehrstabellen« oder »Dialogtabellen« zu führen, in denen die »Conversation Pairs« angezeigt werden. Tabellen, die lediglich die Adapter einzeln als Sender oder Empfänger ausweisen, sind völlig ungenügend.

Abb. 9.5: Beispiel einer Einzeltabelle der Sender (Sources)

Abb. 9.6: Beispiel einer Einzeltabelle der Empfänger (Destinations)

196

Das Auffinden von Fehlern in der Physik

Abb. 9.7: Beispiel einer Dialogtabelle mit den »Conversation Pairs« – hier sortiert nach Zählerstand in der Spalte »Errs(A
Der Unterschied zwischen Dialogtabellen und Einzeltabellen liegt auf der Hand: Bei Einzeltabellen wird jeder Adapter ohne Rücksicht auf Paarbeziehungen aufgelistet; es ist nicht sichtbar, mit wem kommuniziert wird. Bei Dialogtabellen werden die Stationen nicht nur mit ihrer Adapteradresse einzeln aufgeführt, sondern in jeder ihrer Kommunikationsbeziehungen, also etwa: [Server<>Hans], [Server<>Susi], [Router<>Fritz]. Dabei wird für jeweils beide Richtungen (A>B, A
wie viele Frames laufen;

•

wie viele Bytes laufen;

•

wie viele defekte Frames dabei vorkommen.

Hierdurch lässt sich sehr schnell wie folgt verfahren: Die Deutung von Dialogtabellen Anwender Hans-Peter ruft an und beschwert sich. Daraufhin schaut der Techniker auf den Monitor des Analyzers und sucht »Hans-Peter«. (Das setzt natürlich voraus, dass die Namen bereits eingepflegt bzw. hinterlegt wurden!) Dieser kommt in mehreren Verkehrsbeziehungen vor, z.B.: Station A

Station B

Hans-Peter

<>

NetWare-Server

Hans-Peter

<>

Unix-Host

Hans-Peter

<>

WinNT-Server

Hans-Peter

<>

Router

Tab. 9.11: Verkehrsbeziehungen eines Teilnehmers (Beispiel)

Kapitel 9 • Physical Layer

197

Eine solche tabellarische Darstellung führt schnell zu den richtigen Schlüssen: Beispiel A:

Abb. 9.8: Nur Hans-Peter sendet defekte Pakete

Hier ist klar ersichtlich, dass alle defekten Ethernet-Frames nur von Hans-Peter kommen. Daraus folgt: •

bei Koax: Der Adapter ist defekt, sofern kein zweiter Adapter mit defekten Paketen auffällt und sofern Hans-Peter nicht die letzte Station im Koax-Bus ist (die letzte vor dem Endwiderstand). Ist der Adapter von Hans-Peter nicht der letzte vor dem Endwiderstand und sind von den Adaptern zwischen Hans-Peter und dem Endwiderstand sämtliche anderen auch mit defekten Paketen in der Anzeige vertreten, so ist unmittelbar vor dem Adapter von Hans-Peter ein Kabelfehler (Wackelkontakt, Bruchstelle, dämpfungsstarkes T-Stück etc.).

•

bei Twisted-Pair (TP): Hier bleibt offen, ob es der Adapter ist oder das Anschlusskabel; dies ist durch Kabel- oder Adaptertausch zu verifizieren, ggf. durch Hinzunahme eines Kabeltesters.

Beispiel B: Hier ist ebenfalls ersichtlich, wo der Fehler liegt: Nur die Daten von und zum WinNT-Server sind defekt. Da dies auch bei anderen Anwendern der Fall ist, muss der Fehler entweder beim Ethernet-Adapter des NT-Servers zu suchen sein oder bei dessen Anschlusskabel oder am Rx-Port des Verteilers, an dem der WinNT-Server angeschlossen ist. Die letzte Ursache ist damit zwar noch nicht geklärt, aber der Fehler ist hinreichend eingekreist, um nunmehr binnen kurzem die Situation zu bereinigen.

198

Das Auffinden von Fehlern in der Physik

Abb. 9.9: Nur Pakete vom/zum WinNT-Server sind defekt

Beispiel C:

Abb. 9.10: Hans-Peter hat als einziger keine Verbindung zum WinNT-Server

Auch hier ist der Fall klar: Hans-Peter ist zwar mit allen anderen Servern/Routern zu sehen, nicht aber mit dem WinNT-Server. Dafür ist zu sehen, dass Hans-Peters Rechner ständig Broadcasts schickt (z.B. je einen pro Sekunde). Ohne schon in die Frames hineingesehen zu haben, ist zu vermuten, dass der entsprechende Treiber die Broadcasts veranlasst, um mit dem WinNT-Server die Verbindung herzustellen. Der Server aber antwortet nicht oder die Antworten gehen unterwegs verloren. Es ist somit erwiesen (vorbehaltlich der Bestätigung im Protocol Decoding aller Frames), dass es nicht am Adapter oder Anschlusskabel bei Hans-Peter liegt, sondern dass eine logische Störung vorliegt, denn andere Anwender, z.B. Werner, können mit dem WinNT-Server sehr wohl Daten austauschen.

Kapitel 9 • Physical Layer

199

Der logische Fehler kann in der Konfiguration des WinNT-Servers liegen; es kann ein Lizenzproblem sein; es kann sein, dass zwei unterschiedliche Ethernet FrameTypen verwendet werden (das wäre jedoch schon früher aufgefallen; s.u.); es kann ein Routing-Fehler vorliegen. Somit ist der Fehler zwar noch nicht gelöst, aber klar eingegrenzt. Beispiel D:

Abb. 9.11: Session-Absturz zwischen Hans-Peter und WinNT-Server

In diesem Beispiel (hier in der Tabelle nicht wiederzugeben) sind die Zähler bei »Hans-Peter <> WinNT-Server« geradezu »eingefroren«: Sie stehen still, kein Paket läuft mehr zwischen beiden hin oder her. Auch hier ist der Fall klar: Hans-Peter hatte unzweifelhaft bereits Kontakt mit dem WinNT-Server, doch plötzlich wurden alle Übertragungen eingestellt. Da bei allen anderen Anwendern die Zähler weiter nach oben gehen (so z.B. bei Werner), ist dringend von einem Applikations- oder Treiberfehler auszugehen, und dies wiederum aller Wahrscheinlichkeit nach im Client-PC von Hans-Peter.

9.4.7

Der LAN-Analyzer ist unverzichtbar In allen Fällen (und weitere sind möglich!) konnte der Fehler schnell sowohl räumlich wie auch logisch eingekreist werden. Wichtig ist zudem, dass nicht erst ins Frame Decoding gewechselt werden musste, weil bei der Durchsicht der einzelnen Frames immer mit extremem Zeitverlust gerechnet werden muss.

200

Das Auffinden von Fehlern in der Physik

Es ist also von überragendem Belang, dass die wichtigsten Entscheidungen schon auf dem Online-Monitor ersichtlich werden: •

Ist es der Server?

•

Ist es der Client-PC?

•

Ist es das Netzwerk dazwischen?

•

Oder ist es die Logik darüber?

Das recht simple Mittel einer solchen Verkehrsstatistik der Paarbeziehungen kann praktisch immer einen schnellen, zuverlässigen Aufschluss bringen. Diese zentrale Fähigkeit macht den Analyzer einem jedem Kabeltester gegenüber massiv überlegen. Schon allein das Display des Kabeltesters könnte diese Tabellen niemals darstellen.

9.4.8

Beachtung von OSI-Schicht 3/Network Hilfsweise können unter Umständen zur räumlichen Eingrenzung eines physikalischen Fehlers die Subnet-IDs bzw. Netzwerkadressen verwendet werden, die in den Datenpaketen (fast) allenthalben enthalten sind. Hierzu ist es selbstverständlich erforderlich, einen genauen Netzplan zu haben sowie sämtliche ARP-Tabellen (Ethernet-Adressen zu IP-Adressen). Beispiel: Der Analyzer ist am Mirror Port eines Switches angeschlossen, der die Daten von und zu einem der Server ausgibt. Zwar dürften in einem Switched Network keine defekten Ethernet-Pakete mehr zu sehen sein; in Ausnahmefällen jedoch – nämlich bei defekten Routern oder Switches – kann es geschehen, dass Pakete unterwegs sind, die zwar auf MACEbene fehlerfrei erscheinen, im Dateninhalt aber defekt sind. In diesem Falle helfen die in den Paketen enthaltenen Netzwerkkennungen, den Fehler einzukreisen: •

IP-Pakete zeigen anhand der IP-Absenderadresse das Absender-Subnetz.

•

IPX-Pakete enthalten neben der Netzwerkadresse zusätzlich sogar die MACAdresse des Absenders.

Bei inzwischen selten gewordenen Protokollen wie VIP (Banyan Vines) oder DDP (AppleTalk) ist es ähnlich.

Kapitel 9 • Physical Layer

9.4.9

201

Beachtung von OSI-Schicht 4/Transport Hinweise auf physikalische Fehler, die sich außerhalb der Sichtweise des Analyzers ereignen (jenseits von Switch und Router), können oft wenigstens teilweise eingekreist werden durch Nachverfolgen der Data Flow Control auf der Transportschicht; hier arbeiten hauptsächlich TCP und SPX. Analyzer mit eingebautem Expertensystem, etwa Surveyor (Shomiti) und LANdecoder32 (Triticom), zeigen ohne weiteres, dass es Paketwiederholungen oder Überschreitungen von Wartezeiten (Timeouts) gegeben hat. Bei näherer Betrachtung der Netzwerkadressen wiederum (s.o.) wird schnell ersichtlich, wen diese Ereignisse betreffen und wen nicht. Somit ist schnell klar, in welchen fernen (nicht unmittelbar sichtbaren) Netzwerksegmenten Paketverluste auftreten müssen. Im Falle von TCP/IP kann zusätzlich mancher hilfreiche Hinweis gegeben sein, falls Router oder Gegenstellen ICMP-Meldungen zurückgeben. Es muss ergänzend betont werden, dass es hier eigentlich weniger um die Transportschicht an sich ankommt, sondern auf die Data Flow Control zwischen den dialogführenden Rechnern. Elemente von Data Flow Control sind nicht nur in TCP und SPX enthalten, sondern auch in SMB (Microsoft/IBM) und NCP (Novell NetWare), die beide der Schicht 7 (Application) zugeordnet werden. Also können auch hier ggf. Hinweise auf Paketwiederholungen gefunden werden; ReTransmissions dieser Art sind aber selten auf Fehler im Physical Layer zurückzuführen, sondern vielmehr auf Ereignisse der beteiligten Betriebssysteme.

9.4.10 Fazit: Wozu dient ein Kabeltester? Ja, aber?, ... könnte man dann fragen, ... wozu brauche ich dann überhaupt noch einen Kabeltester? Reichen nicht Analyzer und SNMP-Gerätemanagement? Nun – der Kabeltester hat immer noch seine eigene Berechtigung. Er ist notwendig für folgende Arbeiten: •

Werden Kabel neu verlegt, so werden sie zuvor mit dem Kabeltester geprüft; das Messprotokoll wird ausgedruckt, abgezeichnet und zu den Unterlagen gelegt.

•

Wurden die Kabel dann verlegt, werden sie erneut geprüft, bevor sie in Betrieb genommen werden. Auch hier wird das Messprotokoll ausgedruckt und abgeheftet.

•

Ergibt sich später ein Hinweis auf Fehler in der Kabelphysik (z.B. durch entsprechende Aussagen eines LAN-Analysators), wird das betroffene Kabel ausgetauscht und erneut durchgemessen.

202

8B/6T Code-Tabelle

Hierbei muss berücksichtigt werden, dass das ausgetauschte Kabel für den Kabeltester durchaus innerhalb der Norm- bzw. Toleranzwerte liegen kann. Zeigt der LAN-Analysator aber, dass der betroffene Anschluss wieder einwandfrei arbeitet, muss das Kabel »draußen« bleiben – auch, wenn der Kabeltester nichts zeigen konnte. Ergibt der Kabeltest gleichwohl ein klares Ergebnis, so ist dies zur weiteren Qualitätssicherung den Verantwortlichen mitzuteilen: Dem Kabellieferanten, dem Kabelverleger, den eigenen Netzwerkleuten. Der Kabeltester bleibt also weiterhin ein unverzichtbares Mittel der Netzwerküberwachung. Er kann aber sinnvoll nur vor oder nach dem operativen Betrieb genutzt werden; während des operativen Betriebes ist allein der LAN-Analysator sinnvoll. Deutlich milder fällt das Urteil aus bei Netzwerktestern (der fortgeschrittensten Variante der Kabeltester), die ausführliche Diagnosefähigkeiten besitzen, also etwa Server anzeigen können, SNMP- und RMON-Agenten, Router und so fort, und das jeweils mit aussagefähigen Statistiken. Doch auch hier muss anerkannt werden, dass diese Geräteklasse darunter leidet, komplexe Information in einem kleinen Mini-Display kaum sinnvoll darstellen zu können. Auch ist der Mangel an Fähigkeiten wie dem Setzen beliebiger Filter am Ende ausschlaggebend dafür, zusätzlich einen LAN-Analyzer anzuschaffen. Das Preis-Leistungs-Verhältnis spricht von vornherein dafür, eher einen Laptop mit Analyzer anzuschaffen als einen Kabel- oder Netzwerktester, der im Einzelfall sogar teurer sein kann, aber weniger leistet.

9.5

8B/6T Code-Tabelle 8B hex 00 01 02 03 04 05 06 07 08 09 0A 0B 0C

6T bin +-00+0+-+-0 +-0+-0 -0++-0 -0+0+0+--0+ +-0-0+ -0+-0+ -+00+0-++-0 -+0+-0 +0-+-0 +0-0+-

8B hex 40 41 42 43 44 45 46 47 48 49 4A 4B 4C

6T bin +0+00++00-0 +0+0-0 0++0-0 0++00++0-00 +0+-00 0++-00 000+00 000-++ 000+-+ 000++000-+0

8B hex 80 81 82 83 84 85 86 87 88 89 8A 8B 8C

6T bin +-+00++-0-0 +-+0-0 -++0-0 -++00++--00 +-+-00 -++-00 0+00000+0-0 0+00-0 +000-0 +0000-

8B hex C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC

6T bin +-+0+++-+-0 +-++-0 -+++-0 -++0+++--0+ +-+-0+ -++-0+ 0+00+00++-0 0+0+-0 +00+-0 +000+-

Kapitel 9 • Physical Layer

203

0D 0E 0F

0-+-0+ -+0-0+ +0--0+

4D 4E 4F

000-0+ 000+-0 000+0-

8D 8E 8F

00+-00 0+0-00 +00-00

CD CE CF

00+-0+ 0+0-0+ +00-0+

10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F

+0+--0 ++0-0+0+-00++-00++--0 ++00-+0+0-0++0-+0-0+0+-0-+ 0+-++0+-00+ 0-+00+ 0-+++0-+0-+ 0-+0+-

50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F

+0+--+ ++0-++0+-+0++-+0++--+ ++0+-+0++-0+++-+++0-+++-0+++--0 ++0--0 ++0--+ ++000--+++0 00-++0

90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F

+-+--+ ++--++-+-+-++-+-++--+ ++-+-+-++--+++-0+0--+ 00+-+0+0-++00-++00--+ 00++-0+0+-+00+--

D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF

+-+0-+ ++--+0 +-+-+0 -++-+0 -++0-+ ++-+0+-++0-+++00+00-+ 00+-+0 0+0-+0 +00-+0 +000-+ 00++00+0+0+00+0-

20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F

00-++--+00+ ++-0+++-0-+ 00+0-+ 00+0+00-00+ --+++-0-++0 --0+0+ -0-+0+ 0--+0+ 0--++0 --00++ -0-0++ 0--0++

60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F

0-0++0 00-+0+ 0-0+0+ -00+0+ -00++0 00-0++ 0-00++ -000++ -+-++0 --++0+ -+-+0+ +--+0+ +--++0 --+0++ -+-0++ +--0++

A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF

0-0++00-+-+ 0-0+-+ -00+-+ -00++00--++ 0-0-++ -00-++ -+-++--++-+ -+-+-+ +--+-+ +--++--+-++ -+--++ +---++

E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF

+-0++0+-+-+ +-0+-+ -0++-+ -0+++0+--++ +-0-++ -0+-++ -+0++0-++-+ -+0+-+ +0-+-+ +0-++0-+-++ -+0-++ +0--++

30 31 32 33 34 35 36 37 38

+-00-+ 0+--+0 +-0-+0 -0+-+0 -0+0-+ 0+-0++-0+0-0++0-+00-+

70 71 72 73 74 75 76 77 78

-++000 +-+000 ++-000 00+000 -0+000 0-+000 +0-000 0+-000 0--+++

B0 B1 B2 B3 B4 B5 B6 B7 B8

0-000+ 00-0+0 0-00+0 -000+0 -000+0 00-+00 0-0+00 -00+00 -+-00+

F0 F1 F2 F3 F4 F5 F6 F7 F8

+-000+ 0+-0+0 +-00+0 -0+0+0 -0+00+ 0+-+00 +-0+00 -0++00 -+000+

204

8B/6T Code-Tabelle

39 3A 3B 3C 3D 3E 3F

0-+-+0 -+0-+0 +0--+0 +0-0-+ 0-++0-+0+0+0-+0-

79 7A 7B 7C 7D 7E 7F

-0-+++ --0+++ --0++0 ++-0000+00++---+ 00+--+

B9 BA BB BC BD BE BF

--+0+0 -+-0+0 +--0+0 +--00+ --++00 -+-+00 +--+00

Listing 9.1: Coding-Schema von 8B/6T

F9 FA FB FC FD FE FF

0-+0+0 -+00+0 +0-0+0 +0-00+ 0-++00 -+0+00 +0-+00

Kapitel 10 MAC Layer 10.1 10.2 10.3 10.4

Media Access Control Der Aufbau der MAC-Adressen Die Sicherung: Prüfsummen Varianten im Zugriffsverfahren

206 208 217 218

206

10.1

Media Access Control

Media Access Control Wozu dient der MAC Layer (OSI-Schicht 2a)? Diese Frage muss zunächst geklärt werden, da insbesondere Ethernet-Netzwerker den Eindruck haben, eine Ethernet-Karte habe eigentlich nichts weiter zu tun als dann und wann zu senden oder zu empfangen. Ganz so einfach ist es nicht – spätestens bei Token-Ring fängt MAC an, doch kompliziert zu sein.

10.1.1 Kernfunktionen von MAC Folgende Aufgaben hat der MAC-Layer in LANs vorrangig zu erfüllen: •

Zugriffsberechtigung Auf der MAC-Ebene wird entschieden, wer wann (wieviel) senden darf.

•

Adressierung der LAN-Adapter Eine weitere Aufgabe der MAC-Ebene ist die Adressierung der Endgeräte durch eindeutige Adressen.

•

Sicherung durch CRC Der Empfänger wird gegen Fehler in den Datenpaketen durch Prüfsummen (CRC) geschützt. Daher wird der MAC-Layer im Deutschen auch oft »Sicherungsschicht« genannt.

10.1.2 Die Zugriffsberechtigung Zugriffsberechtigung = Sendeberechtigung Auf der MAC-Ebene wird entschieden, wer wann (wie viel) senden darf. MAC = Media Access Control = Medien-Zugangs-Verfahren. Da die klassischen LANs der 80er Jahre auf Shared Media betrieben wurden (alle waren an dasselbe Kabel angeschlossen und benutzten dieselbe Frequenz), musste sichergestellt werden, dass immer nur ein Adaper zu einer Zeit sendete.

10.1.3 Das MAC-Protokoll Das MAC-Protokoll steuert den Zugriff der Endgeräte auf das Netzwerk. Da im Kabel jeweils nur ein Signal zu einer Zeit fehlerfrei übertragen werden kann, dürfen nicht mehrere Endgeräte gleichzeitig Daten senden. Mit geeigneten Maßnahmen muss der Sendevorgang der Rechner gesteuert werden.

Kapitel 10 • MAC Layer

207

Gängige MAC-Protokolle sind: MAC Protocol

Topologie/Bezeichnung

Entwickler

CSMA/CD

IEEE 802.3/Ethernet

Xerox, DIX

Token Passing Bus

IEEE 802.4/Token Bus

General Motors

Token Passing Ring

IEEE 802.5/Token Ring

IBM

Distributed Queue Dual Bus

IEEE 802.6/MAN DQDB

--

Token Passing Ring

ANSI X3T9.5/FDDI

ANSI

Token Passing Star

ARCnet

DataPoint

Tab. 10.1: Gängige MAC-Protokolle und ihre Topologien

Es muss gesehen werden, dass jedes Protokoll für eine typische räumliche Anordnung der Kabel und für eine typische Art der Verbindung verschiedener Kabel entwickelt wurde. Auf einem Bus-System wie Ethernet ist ein Kollisionsprotokoll genau so denkbar wie ein Token-Protokoll; auf einem Ring jedoch ist nur ein Token-Protokoll oder ein Slot-Protokoll (ähnlich ATM) denkbar bzw. machbar. Daher entstand auch das Wort von den »Topologien«: Jeder Topographie (räumlichen Anordnung) entspricht eine bestimmte Logik im Medienzugriff: [Topographie] + [MAC-Logik] = Topologie Topographie

Kabel (ohne LWL)

Toplogien/MAC-Protokoll

Stern (star)

Koax, TP

ARCnet, Ethernet

Ring (ring)

TP (IBM Typ 1, Cat-4/5)

Token-Ring, FDDI, MAN DQDB

Bus (bus)

Koax, TP

ARCnet, Ethernet

Tab. 10.2: Zusammenhang von Topographie, Kabel und MAC-Protokoll

Die Tabelle 10.1 lässt IEEE 802.4 außer Acht, da schon Ende der 80er Jahre damit im LAN kaum noch gearbeitet wurde; es war als Protokoll zur Maschinensteuerung entwickelt worden und hat in Office-LANs kaum Einzug gefunden. Es zeigte sich, dass zwar Ring-Topologien ein hohes Maß an Redundanz erreichen können, dass sie aber für Switched Networks keinen Sinn mehr ergaben. Dies erklärt u.a., warum Ethernet »das Rennen gewonnen« hat.

208

Der Aufbau der MAC-Adressen

10.1.4 Die Adressierung: MAC-Adressen Alle LAN-Topologien waren als Shared Media LANs entwickelt worden: Alle teilen sich dasselbe Kabel bzw. auf dem gegebenen Medium dieselbe Frequenz. Wo nicht zu jedem Teilnehmer eine eigene Leitung führt (vermaschte Netze, geschaltete Netze), sondern wo alle Teilnehmer an derselben Leitung angeschlossen sind, kommt der Adressierung eine andere Bedeutung und Ausprägung zu wie etwa in Telefonnetzen. Folgende Punkte können als vorrangig angesehen werden: •

Adressierung der Netzwerk-Stationen Eine weitere Aufgabe der MAC-Ebene ist die Adressierung der Endgeräte.

•

Broadcast LAN/Shared Media Da jedes Datenpaket im gesamten Netzwerk von allen Rechnern eingelesen wird, muss durch die Angabe der Knotenadresse der richtige Empfänger spezifiziert werden.

•

Einmaligkeit der Adresse Jede LAN-Adapter-Karte, die nach IEEE-Standard gefertigt wird, hat eine weltweit einmalige/eindeutige Kennung. Zur genauen Identifizierung der Kommunikationspartner enthält der MACHeader neben der Empfänger- immer auch die Absenderadresse.

Die Einmaligkeit der Adresse ist nicht mehr garantiert, wenn die »burned-in address«, also die werksseitig eingebrannte und den weltweit geltenden IEEERegeln folgende MAC-Adresse (Universally Administered Address, UAA) über den Software-Treiber verändert wird (Locally Administered Address, LAA). Dies führt zum Aufbau der MAC-Adressen.

10.2

Der Aufbau der MAC-Adressen Zunächst muss der Aufbau der MAC-Adressen geklärt werden. Bei den von IEEE standardisierten LAN-Topologien haben alle Stationsadressen ein einheitliches Format; FDDI hat dieses Adressformat vom IEEE übernommen. MAC-Adressen sind 6 Byte (6 Octets) lang, mit einer Herstellerkennung in den ersten drei Bytes sowie dem eigentlichen Stationszähler in den zweiten drei Bytes. Die von IEEE zwecks Abwärtskompatibilität einst ebenfalls zugelassenen alten Adressen mit Länge von 2 Byte sind heute belanglos und werden nicht mehr verwendet.

Kapitel 10 • MAC Layer

209

Abb. 10.1: IEEE MAC Destination Address – I/G-Bit & U/L-Bit

10.2.1 Manufacturer ID und Node ID Jede IEEE-MAC-Adresse besteht heute also aus einer 6-Byte-Kennung, bestehend aus: •

3 Byte Herstellerkennung (abzüglich der ersten 2 Bit)

•

3 Byte Stationskennung

Diese Adressen sind fest in einem Speicherbaustein des Adapters eingebrannt (»burned-in address«; »hardware address«). LAN-Analysatoren erkennen die Herstellerkennungen, sofern die hinterlegten Tabellen entsprechend gepflegt, also auf dem aktuellsten Stand gehalten werden. Große Hersteller haben durchaus mehrere Kennungen für verschiedene Adaptertypen bzw. Adapterserien und tauchen darum in aller Regel öfter auf. Dies ist auch der Fall, wenn ein Hersteller mit seinem Code von einem anderen aufgekauft wird. Tatsächlich füllt die Herstellerkennung des IEEE nicht die ersten drei Oktette vollständig, da die ersten zwei Bits für andere Zwecke reserviert sind – die sog. I/G- und U/L-Bits. Das U/L-Bit zeigt an, ob eine »LAA« oder »UAA« verwendet wird.

210

Der Aufbau der MAC-Adressen

10.2.2 OUI = Organizationally Unique Identifier Die Herstellerkennung in den ersten drei Oktetts einer MAC-Adresse (UAA) werden seitens des IEEE auch bezeichnet als: OUI = Organizationally Unique Identifier. Diese Bezeichnung gilt jedoch nicht ausschließlich für Herstellerkennungen innerhalb von MAC-Adressen, sondern auch für solche im LLC-SNAP-Header.

10.2.3 LAA und UAA Da die Herstellerkennung vom IEEE weltweit gültig vergeben wird, und da der Hersteller nach IEEE verpflichtet ist, jede vergebene Node ID nur genau einmal zu verwenden; darum heißt die »burned-in address« in der Sprache von IEEE »Universally Administered Address« (UAA); im Gegensatz hierzu stehen nachträglich über den Treiber vergebene MAC-Adressen (»Locally Administered Address«, LAA). Adress-Typ (Abk.)

Bedeutung

UAA

Universally Administered Address Hierbei handelt es sich um die vom Hersteller werksseitig eingebrannte MAC-Adresse, die dem Vergabeschema des IEEE folgt. Nur bei der UAA findet die Unterteilung in Herstellerkennunng und Stationszähler statt.

LAA

Locally Administered Address Hierbei handelt es sich um eine vom lokalen Netzwerk-Administrator (oder Anwender) vergebene MAC-Adresse, die beliebigen Schemata folgen kann.

Tab. 10.3: Verschiedene Typen von MAC-Adressen: UAA und LAA

Bei Verwendung von LAA geht die Information über den Hersteller des Adapters insofern verloren, als sie in den MAC-Adressen auf der Leitung nicht mehr sichtbar wird.

10.2.4 I/G-Bit und U/G-Bit Die ersten zwei Bits des ersten Adress-Oktetts einer jeden MAC Destination Address (Empfängeradresse) enthalten zusätzliche Angaben, die nicht eigentlich zur Stationsadresse gehören:

Kapitel 10 • MAC Layer

211

Bit-Bezeichnung

Bedeutung

I/G bit

Individual or Group Address 0 = Individual Address Das I-Bit zeigt an, dass die nachfolgende MAC-Adresse nur einen einzelnen, unverwechselbaren Teilnehmer als Empfänger anspricht. 1 = Group Address = Multicast/Broadcast Das G-Bit zeigt an, dass die nachfolgende MAC-Adresse alle Teilnehmer (Broadcast) oder eine Gruppe von ihnen (Multicast) als Empfänger anspricht. MAC-Multicasts werden z.B. bei der Geräteverwaltung verwendet, um etwa alle Switches eines Herstellers anzusprechen. I-Bit und L-Bit können gemeinsam gesetzt sein.

U/L bit

Universally or Locally Administered Address 0 = UAA = Universally Administered Address Das U-Bit zeigt an, dass die nachfolgende Adresse des Empfängers eine vom Hersteller werksseitig eingebrannte MAC-Adresse nach IEEE-Konvention ist. 1 = LAA = Locally Administered Address Das L-Bit zeigt an, dass die nachfolgende Adresse des Empfängers eine logische Adresse ist, keine Herstelleradresse. I-Bit und L-Bit können gemeinsam gesetzt sein.

Tab. 10.4: Das I/B-Bit und das U/L-Bit in der MAC Destination Address

Die MAC Source Address ist etwas anders aufgebaut als die Empfängeradresse: Bit-Bezeichnung

Bedeutung

RII bit

Routing Information Indicator 0 = No RIF Present RII=0 zeigt an, dass hinter der MAC Source Address kein RIF (Routing Information Field) mit Angaben zum Source-Routing folgt. Dies ist bei Ethernet immer der Fall, da Ethernet nicht mit Source-Route Bridging arbeitet, sondern mit Transparent Bridging. 1 = RIF Present RII=1 zeigt an, dass hinter der MAC Source Address ein RIF (Routing Information Field) mit Angaben zum Source-Routing folgt. Dies ist nur bei Token-Ring der Fall, wenn mit Source-Route Bridging gearbeitet wird.

U/L bit

Universally or Locally Administered Address (Bedeutung: wie bei der MAC Destination Address, s.o.)

Tab. 10.5: Das RII-Bit und das U/L-Bit in der MAC Source Address

212

Der Aufbau der MAC-Adressen

Hier sei auf das Kapitel zur Token-Ring-Analyse verwiesen, wo die Token-Ring MAC-Adressen eigene Berücksichtigung finden.

10.2.5 MSB/LSB – kanonisch/non-kanonisch Trotz des grundsätzlich immer gleichen Schemas gibt es Unterschiede in der binären Darstellung der MAC-Adressen (MSB vs. LSB, kanonisch vs. non-kanonisch). MSB vs. LSB/kanonisch vs. non-kanonisch • Bei Ethernet (IEEE 802.3) und Token-Bus (IEEE 802.4) werden die einzelnen Oktette dergestalt gesendet, dass das LSB (das niederwertigste Bit) zuerst übertragen wird; diese Übertragungsweise wird »kanonisch« (canonical) genannt. •

Bei Token-Ring (IEEE 802.5) und FDDI (ANSI X3T9.5) wird das MSB (das höherwertigste Bit) zuerst übertragen; diese Übertragungsweise wird »nonkanonisch« (non-canonical) genannt.

•

Bridges zwischen Ethernet einerseits und FDDI/Token-Ring andererseits verlangen daher ggf. ein Umsetzen der jeweiligen MAC-Adresse.

Nach IEEE-Standard sollen zwar die MAC-Adressen übereinstimmend im LSBModus übertragen werden; sie werden dann aber nach der Verarbeitung im Token-Ring LAN-Adapter gleichwohl im MSB-Mode verarbeitet und dargestellt. Somit ist die Trennung bei Token-Ring, die MAC-Adressen zwar im LSB-Mode und den Inhalt des Datenpakets im MSB-Mode zu senden, für die Arbeit mit dem Analyzer praktisch hinfällig, da intern dann doch die Umwandlung erfolgt – und damit auch die abweichende Darstellung zwischen Ethernet und Token-Ring. Allgemein kann im Falle eines Bridgings/Switchings von Ethernet zu Token-Ring an den Geräten eingestellt werden, ob eine Umwandlung in der binären Darstellung stattfinden soll. Hier sind Vor- und Nachteile abzuwägen: Umwandlung

Bewertung

JA

Vorteil: Die für Ethernet bzw. Token-Ring jeweils typischen Adressmerkmale bleiben erhalten. Nachteil: Der LAN-Analyst kann z.B. seine vertrauten Token-Ring-MACAdressen auf Ethernet nicht mehr wiedererkennen.

NEIN

(wie oben, nur umgekehrt)

Tab. 10.6: Vor- und Nachteile einer binären Adressumwandlung

Kapitel 10 • MAC Layer

213

Allerdings ist diese Diskussion heute fast hinfällig, da es nur noch selten zu der Gelegenheit kommt, zwischen verschiedenen Topologien mit Brücken zu arbeiten. Seitdem die Router durch Hardware-Verfahren nahe an die Leistung von LANSwitches herangekommen sind, kann auch mit Routing getrennt bzw. verbunden werden. Außerdem hat die immer weiter voranschreitende Homogenisierung der LANs zu reinen Ethernet-Strukturen das Leben diesbezüglich ebenfalls stark erleichtert. Aus der jeweils unterschiedlichen Verwendung der MSB- bzw. LSB-Übertragungen folgen Unterschiede in der Darstellung logischer Adressen bzw. ihrer Bestandteile:

10.2.6 Unterschiedliche Darstellung logischer Adressen Die folgenden Darlegungen beziehen sich auf das erste Oktett einer MAC Destination Address bzw. auf die darin enthaltenen ersten zwei Bits (I/G, U/L).
 
      

Belegung der Bit

1. Oktett

Bedeutung

I/G = 0

0x00 Token-Ring 0x00 Ethernet

Es handelt sich um eine individualle Empfängeradresse.

I/G = 1

0x80 Token-Ring 0x01 Ethernet

Es handelt sich um eine Multicast- oder Broadcast-Adresse.

Tab. 10.7: Bedeutung und Darstellung des I/G-Bits           

Belegung der Bit

1. Oktett

Bedeutung

U/L = 0

0x00 Token-Ring 0x00 Ethernet

Es handelt sich um eine UAA = Universally Administered Address.

U/L = 1

0x40 Token-Ring 0x02 Ethernet

Es handelt sich um eine LAA = Locally Administered Address.

Tab. 10.8: Bedeutung und Darstellung des U/L-Bits
    

Belegung der Bit

1. Oktett

Bedeutung

I/G = 0 U/L = 0

0x00 Token-Ring 0x00 Ethernet

Es handelt sich um eine UAA = Universally Administered Address sowie um eine individualle Empfängeradresse Beispiel: Die originale Hardware-Adresse eines LAN-Adapters (»burned-in address«).

214

Der Aufbau der MAC-Adressen

Belegung der Bit

1. Oktett

Bedeutung

I/G = 0 U/L = 1

0x40 Token-Ring 0x02 Ethernet

Es handelt sich um eine LAA = Locally Administered Address sowie um eine individuelle Empfängeradresse. Beispiel für Token-Ring: 400030-47B1A1 = Logische Adapteradresse eines IBM LAN-Servers. Beispiel für Ethernet: 020047-110815 = Beliebige logische Adapteradresse eines beliebigen Ethernet-Adapters.

I/G = 1 U/L = 0

0x80 Token-Ring 0x01 Ethernet

Es handelt sich um eine UAA = Universally Administered Address sowie um eine Gruppenadresse (Multicast/Broadcast) seitens des/der Empfänger. Beispiel für Ethernet: 0180C2-000000 = Funktionsadresse: weltweit gültige Multicast-Adresse für Spanning Tree Bridges (BPDU Multicast Address). Beispiel für Token-Ring: 800143-000008 = Funktionsadresse: weltweit gültige Adresse, die im Token-Ring das Bridge Management anspricht.

I/G = 1 U/L = 1

0xC0 Token-Ring 0x03 Ethernet

Es handelt sich um eine LAA = Locally Administered Address sowie um eine Gruppenadresse (Multicast/Broadcast) seitens des/der Empfänger. Beispiel für Ethernet: 030000-000001 = Funktions- und Multicast-Adresse für NetBIOS-Stationen. Beispiel für Token-Ring: C00000-000008 = Funktions- und Multicast-Adresse für den Ring Error Monitor (REM).

Tab. 10.9: Bedeutung und Darstellung der I/G- und U/L-Bits gemeinsam

Kapitel 10 • MAC Layer

215

   Modus (LSB/MSB)

Übertragung auf der Leitung

Interne Darstellung der Bits binär

Interne Darstellung der Bits hexadezimal

LSB

<< 01000000 <<

MSB 00000010 LSB

0x02 (Ethernet)

MSB

<< 01000000 <<

MSB 01000000 LSB

0x40 (Token-Ring)

LSB

<< 11000000 <<

MSB 00000011 LSB

0x03 (Ethernet)

MSB

<< 11000000 <<

MSB 11000000 LSB

0xC0 (Token-Ring)

Tab. 10.10: Binäre und hexadezimale Darstellung von LSB und MSB

Automatisches Setzen der I/G-U/A-Bit Die I/G- und U/L-Bits sind nicht Teil der Herstellerkennung innerhalb MACAdresse, sondern sind dieser vorangestellt. Der Hersteller-Code (OUI, Organizationally Unique Identifier) ist lediglich 6+8+8 Bit lang. Weiterhin ist es so, dass diese Bits automatisch gesetzt werden. Dies ist insbesondere für das U/L-Bit wichtig. Der Treiber eines LAN-Adapters setzt das U/L-Bit selbstständig: Wird ein LAN-Adapter angewiesen, die LAA "000011223344" zu verwenden, erscheint bei Ethernet auf der Leitung die MAC Source Address "020011223344", bei Token-Ring "400011223344".

10.2.7 Sicherheit vor MAC-Spoofing und Hackern (Spoofing = so tun, als wäre man ein anderer) Auf diese Weise ist es absolut unmöglich für Hacker, eine UAA (also eine »burned-in MAC address«) tatsächlich nachzuahmen: Ein solcher Versuch kann zwar erreichen, dass die tatsächlichen Adress-Bits 5–48 (bzw. 4–47) imitiert werden; da aber der Adapter bzw. sein Treiber selbsttätig das U/L-Bit »kippt«, wird die gewünschte Adresse durch U/L=1 verfälscht. Völlig unsicher dagegen sind LAA: Jederzeit kann ein Hacker mit seinem eigenen Rechner beliebige andere LAA im LAN imitieren. Aus Sicherheitsgründen sollte darum drei Mal überlegt werden, bevor man eine UAA durch eine LAA ersetzt. Token-Ring Bei Token-Ring gibt es diesen Zwang zur LAA nur noch in wenigen Fällen, so bei der gleichen MAC-Adresse für die verschiedenen LAN-Zugänge des SNAHosts (Gateway-TICs).

216

Der Aufbau der MAC-Adressen

Die Funktion von Token-Ring, dass jeder Adapter, der neu in den Ring kommt, einen Duplicate Address Test (DAT) durchführt, um sicherzustellen, dass nicht bereits ein zweiter Adapter zuvor mit derselben Adresse (wie seine eigene) im Ring aktiv wurde, kann nur begrenzt Sicherheit schaffen, da der DAT nur im jeweiligen, begrenzten Ringsegment arbeitet – der DAT läuft nicht über Brücken oder Router. Der etwas altertümlich anmutende IBM OS/2 LAN Network Manager hat dagegen die Möglichkeit, über alle Brücken und Ringe hinweg die MAC-Adressen auf Einmaligkeit hin zu überprüfen und ggf. doppelte Adressen zu melden. Der IBM OS/2 LAN Network Manager ist sogar in der Lage, unerwünschte Adapter aus dem Ring zu werfen mit dem Befehl des MAC-Protokolls »Remove Adapter«. Die Zahl der Installationen dieser Management-Plattform aber ist in den letzten Jahren fortlaufend zurück gegangen. Auch muss sich noch zeigen, ob der IBM OS/2 LAN Network Manager das Y2K-Szenario überlebt. Es darf daher nicht auf den DAT vertraut werden, wenn es um die Einmaligkeit von LAA geht. Ethernet Ethernet kennt überhaupt keine eigenständige Absicherung gegen doppelte MACAdressen. Hier kann allein intelligentes Netzwerk-Management und LAN Monitoring helfen. VLANs Gut sieht es aus in VLANs, da hier vollständige Adresstabellen hinterlegt werden können und die einzelnen MAC- und IP/IPX-Adressen sogar noch an bestimmte Switch-Ports gebunden werden können. VLANs sind eine unabdingbare Notwendigkeit, wenn totale Sicherheit gegenüber Spoofing-Angriffen hergestellt werden muss.

10.2.8 MAC-Spoofing und IP-Spoofing Eine bekannte Herangehensweise von Hackern, die im Unternehmen selber sitzen, das angegriffen werden soll, ist es, wie folgt vorzugehen: Einem beliebigen Rechner (vermutlich einem mit Linux präparierten Laptop) wird die IP-Adresse eines bestimmten Rechners im Unternehmen gegeben. Dies ist weniger die IP-Adresse eines Servers als vielmehr die IP-Adresse eines Rechners, der für sich allein, oder dessen Anwender besondere Berechtigung besitzt, auf Daten eines dritten Servers zuzugreifen. Sodann versucht der Hacker, sich mit der Berechtigung eines anderen Mitarbeiters an dem dritten Rechner, einem Server, anzumelden. IP-Spoofing ist besonders gefährlich dort, wo mit NFS gearbeitet wird.

Kapitel 10 • MAC Layer

217

Ganz abgesehen davon, dass die angemessenen Antworten auf solche HackerAngriffe inzwischen •

Switching

•

VLAN

•

Firewall

heißen, ist in Betracht zu ziehen, inwiefern die MAC-Adresse eines Zugang begehrenden Rechners neben seiner IP-Adresse heranzuziehen ist. Intelligente LAN Monitoring Software bzw. gute Mangementagenten in den aktiven Komponenten (Bridges, Switches, Router, RMON-Probes) erkennen automatisch, ob sich zu einer IP-Adresse die MAC-Adresse geändert hat (oder umgekehrt).

10.3

Die Sicherung: Prüfsummen Eine wichtige MAC-Funktion ist die Absicherung der Datenpakete (Frames) durch Prüfsummen. Der Empfänger wird gegen Fehler in den Datenpaketen durch Prüfsummen geschützt: Der Absender bildet eine Prüfsumme über die gesendeten Daten und sendet die letzten 32 Bits der Prüfsumme als sog. FCS (Frame Check Sequence) mit. Der Empfänger vergleicht das mitgelieferte Prüfsummenfragment mit der Prüfsumme, die er selber über die Daten bildet. Stimmen beide Prüfsummen nicht überein, liegt ein Bitfehler vor und das Paket wird verworfen. Eine Wiederherstellung defekter Bits, wie sie moderne Prüfsummentechniken erlauben, findet in LANs nicht statt. Praktisch jeder LAN-Analysator zeigt defekte Prüfsummen an:

Abb. 10.2: Darstellung von Ethernet-Frames mit defekter Prüfsumme (LANdecoder32)

218

Varianten im Zugriffsverfahren

Abb. 10.3: Statistik über Ethernet-Fehler (LANdecoder32)

Defekte Prüfsummen werden zwar auf dem MAC Layer erkannt, bezeichnen aber doch Fehler aus dem Physical Layer, weswegen sie an dieser Stelle nicht weiter berücksichtigt werden sollen (siehe Kapitel zur Analyse im Physical Layer).

10.4

Varianten im Zugriffsverfahren Ethernet (IEEE 802.3), Token Bus (IEEE 802.4) und Token Ring (IEEE 802.5) unterscheiden sich in ihrem Zugriffsverfahren erheblich: Während die beiden Token-Protokolle mit einem Senderecht – dem Token – arbeiten, das von Station zu Station im (logischen oder physikalischen) Kreis herumgereicht wird, kann bei CSMA/CD jede Station (solange die Leitung frei ist) senden, wann sie will. Daher ist bei 802.4- und 802.5-Netzwerken das Verhalten des Netzwerkes unter Last mathematisch ziemlich genau bestimmbar, während – umgekehrt – der zufällige Zugriff aufs Medium bei 802.3 keine genauen Vorhersagen zulässt. Deswegen werden die Token-Protokolle als deterministische und Ethernet als non-deterministisches oder stochastisches Zugriffsverfahren bezeichnet. Das Ethernet-Verfahren ist darüber hinaus als Contention bekannt, was etwa als »Wettstreit« der Beteiligten im Kampf um den Zugriff aufs Übertragungsmedium übersetzt werden könnte. (Das darf nicht verwechselt werden mit der Monitor Contention bei Token-Ring, wenn ein neuer Active Monitor ausgehandelt wird, einer der zentralsten MAC-Funktionen bei Token-Ring überhaupt.) In Netzwerken, die mit Switching arbeiten, wird ggf. die Entscheidung, wer wann senden darf, allein vom Switch getroffen. Dies ist der Fall bei 100VG-AnyLAN und ATM. LAN-Analysatoren entsprechen der Tatsache verschiedener MAC-Verfahren, indem die Darstellungen des LAN-Geschehens unterschiedlich sind.

Kapitel 11 Fehler auf dem MAC-Layer 11.1 11.2 11.3 11.4

Doppelte MAC-Adresse(n) (LAA) Broadcast Storms Spanning Tree Bridges Die Bedeutung der Analyse auf Schicht 2–7

220 222 226 235

220

Doppelte MAC-Adresse(n) (LAA)

Es gibt eine übersichtliche Zahl von Fehlern auf dem MAC-Layer, die (weitgehend) unabhängig vom Physical Layer und (weitgehend) unabhängig von der aktuellen LAN-Topologie auftreten. Alle weiteren Fehler, die den MAC Layer betreffen und in diesem Abschnitt keine Erwähnung finden, müssen in den jeweiligen Kapiteln zu Ethernet und TokenRing gesucht werden, aber auch im Einführungskapitel zur grundsätzlichen Analyse-Methodik.

11.1

Doppelte MAC-Adresse(n) (LAA) Ein typischer Fehler in LANs auf dem MAC Layer sind doppelte MAC-Adressen – nicht aber als Folge von MAC-Spoofing (siehe oben), sondern als Folge von Konfigurationsfehlern.

11.1.1 Das Szenario 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-MAC-Adressen (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. Und doch: Es gibt LAN-Admins, die sich den LAA-Mechanismus zuhilfe 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 Hersteller-Code 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:

11.1.2 Lokaler Konfigurationsfehler Es wurde in der Windows-Systemsteuerung (oder sonstwo in der Treiberkonfiguration) auf mehreren Rechnern dieselbe logische MAC-Adresse eingetragen.

Kapitel 11 • Fehler auf dem MAC-Layer

221

11.1.3 Fernkonfiguration mittels RPS 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.

11.1.4 Nachweis von doppelten MAC-Adressen Es gibt verschiedene Hinweise oder Nachweise: •

Bei zwei LAN-Stationen bleiben abwechselnd die Applikationen oder HostSessions stehen oder sie stürzen abwechselnd ab. Dies allein ist schon ein starker Hinweis auf eine doppelte MAC- und/oder IP-Adresse.

•

Der Analyzer bzw. sein Expertensystem zeigt dies automatisch an.

•

Komponenten des Netzwerkmanagements zeigen das an.

Abb. 11.1: Automatische Anzeige einer doppelten MAC-Adresse (LANdecoder32)

11.1.5 Behebung des Fehlers Die Behebung des Fehlers hängt ab von der Ursache; in aller Regel zeigt sich, dass Einstellungen an PCs falsch waren – ein kleiner Eingriff reicht zumeist, um den Fehler abzustellen.

222

11.2

Broadcast Storms

Broadcast Storms Im weitesten Sinne gehören Stürme von LAN-Broadcasts zu den Fehlern des MAC Layers. Warum diese Einschränkung: »im weitesten Sinne«? Nun – wenn übermäßig viele LAN-Broadcasts auf der Leitung sind, so spielt sich das zwar eindeutig auf dem MAC-Layer ab, aber damit ist noch lange nicht gesagt, dass es sich um einen Fehler des MAC-Layers handelt, dass also die Ursache in dieser Funktionsschicht liegt.

11.2.1 Mögliche Ursachen von Broadcast Storms Als Möglichkeiten kommen hauptsächlich folgende Ursachen oder Ereignisse infrage: Mangelnder Schutz durch Bridges/Switches Bridges/Switches wurden nicht darauf eingestellt, Broadcast Storms zu erkennen und zu unterdrücken. Hierbei handelt es sich nur um eine Sekundär-Folge, da es die Ursache der Broadcasts nicht berührt. Gleichwohl sollten Bridges und Switches so konfiguriert werden, dass sie diese Schutzfunktion wahrnehmen. Dies geschieht so, dass ein Schwellwert gesetzt wird, der definiert, wie viele Broadcasts pro Sekunde die Bridge/der Switch weitergeben darf. Wird der Schwellwert überschritten, werden alle weiteren Broadcasts bis zum Ablauf der aktuellen Sekunde unterdrückt; außerdem wird per SNMP eine Trap-Meldung an die Management-Console geschickt. Vervielfältigung von Frames (1) durch Backbone-Switches Backbone-Switches vervielfältigen selbstständig und fehlerhaft Frames – normale Frames und/oder Broadcast Frames. Der Autor konnte dies in der Vergangenheit sowohl bei FDDI-Backbone-Ringen wie auch in ATM-Backbone-Netzen nachweisen. In beiden Fällen wurden teilweise mehrere Hundert oder Tausend Kopien von jeweils einem einzigen Broadcast Frame erzeugt, was auf den angeschlossenen LAN-Segmenten wie auch im Backbone als geringste Folge die Leitung verstopfte und die Antwortzeiten verlängerte; im schlimmsten Fall gaben PCs schlicht ihren Geist auf, weil die hohe Zahl an Interrupt-Auslösungen die PCArchitektur überforderte (Hardware wie Betriebssystem). Vervielfältigung von Frames (2) durch Source-Route Bridges Eine – ganz legale! – Vervielfältigung kann eintreten, wenn eine große Zahl von Ringen, in denen mit Token-Ring Source-Routing gearbeitet wird, sehr stark unter einander vermascht ist.

Kapitel 11 • Fehler auf dem MAC-Layer

223

In einem Falle sehr hoher Vermaschung konnte der Autor bei einem Kunden nachweisen, dass aus einem einzigen All Routes Broadcast (ARB) mehrere Dutzend wurden! Wenn morgens früh die Mitarbeiter kamen (mehrere Hundert) und die üblichen Broadcasts zum Verbindungsaufbau (SNA Host, LAN Server) gesendet wurden – dann brachen Broadcast-Stürme los, die gleich massenhaft die Server im Rechenzentrum zusammenbrechen ließen. Teilweise starb praktisch die ganze Server-Farm auf einmal. Der einzige »Schutz« war dann, die Vermaschung teilweise durch Ausschalten einer bestimmten Source-Route Bridge so zu reduzieren, um die Zahl der ARBs soweit zu vermindern, dass wenigstens die Server nicht mehr abstürzten. Hierbei handelt es sich im weitesten Sinne nicht unbedingt um einen Fehler – es handelt sich um die simple Folge einer gewollten oder ungewollten Konfiguration. Im konkreten Falle des Kunden »bissen« sich auf mehreren Hundert Endgeräten die 3270-Terminal-Emulation und verschiedene IP/IPX-Anwendungen, die den Token-Ring Adaptertreiber unterschiedlich bedienten: Während die 3270-Emulation den Treiber ständig auf »ARB« setzte, wenn es galt, das SNA-Gateway zu suchen (etc.), verzichteten die IP/IPX-Anwendungen darauf, den Adaptertreiber zurückzusetzen auf Non-Source-Route Broadcasts (also normale LAN Broadcasts). Die Client-Server-Anwendungen waren offenkundig auf Ethernet programmiert worden und niemand hatte daran gedacht, dass vielleicht auch mal Token-RingKunden dabei sein könnten. So waren die IP/IPX-Anwendungen hilflos einem Adaptertreiber ausgesetzt, der seine Einstellungen von der 3270-Emulation gesetzt bekam – und der bei dieser Einstellung blieb, weil ihm nichts anderes gesagt wurde. Dieser Fehler ist zwar kein universeller Fehler im MAC-Layer, sondern an TokenRing gebunden, soll hier aber aufgeführt werden, (a) weil teilweise noch Ethernet-zu-Token-Ring Bridging stattfindet, was auch Ethernet-Segmente beeinflussen könnte, (b) weil es in der Systematik dieses Abschnittes durchaus sinnvoll ist, auf diesen speziellen Fall der Paketvervielfältigung hinzuweisen. Im günstigsten Fall schafft eine Umstellung in der Windows-Registry Abhilfe, und zwar so, dass bei ARP-Broadcasts entweder nur mit SRBs oder ganz ohne Source-Routing gearbeitet wird: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters\ArpAlwaysSourceRoute HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters\ArpTRSingleRoute

224

Broadcast Storms

Verfälschung von Frames durch Switches (1): I/G-Bit Ein sehr seltener Fehler ist die Verfälschung von normalen LAN Frames durch Backbone Switches in der Form, dass diese fehlerhaft in den durchlaufenden Paketen das I/G-Bit von »0« auf »1« kippen – mit fataler Wirkung: Während normalerweise I/G=0 bewirkt, dass ein Switch den LAN Frame nur an dem einen Switch Port ausgibt, hinter dem der Empfänger bekannt ist, werden Frames mit I/G=1 zwingend an allen Switch Ports ausgegeben. Wenn dies geschieht, und nicht nur sporadisch, sondern massenhaft, geht das LAN praktisch sofort in die Knie – alle angeschlossenen Komponenten werden schnell wegen Überlastung Pufferüberlauf erleiden und Pakete verwerfen, außerdem werden sämtliche Leitungen geflutet und somit verstopft – die Antwortzeiten für die Anwender werden unerträglich lang und ggf. stürzen Rechner bei diesem Szenario sogar ab, etwa mit einem Blue Screen. Verfälschung von Frames durch Switches (2): ARB-Bits Ein ähnlicher Fehler, der vom Autor leider öfter beobachtet werden konnte, war, dass LAN-Frames im Token-Ring irrtümlich als All Routes Broadcasts (ARB) unterwegs waren, obwohl sie überhaupt nicht als Broadcast gedacht waren oder gedacht sein sollten. Der Fehler kann schon beim Absender liegen, wenn dort der Token-Ring-Treiber defekt oder falsch eingestellt ist, oder wenn Einträge in der Windows-Registry nicht korrekt sind. Der Fehler kann aber auch (wie oben) durch LAN-Bridges oder LAN-Switches erzeugt werden, die in den LAN-Frame eingreifen und ihn zum ARB umstempeln, obwohl er dies nicht war/ist und obwohl dies nicht sein dürfte. Fehler in Protokollen wie NetBIOS oder Diensten wie z.B. WINS Wird nicht bei Win95/98-Workgroups oder WinNT-Domänen konsequent die Auflösung von NetBIOS-Namen in IP-Adressen oder MAC-Adressen über WINS-Server oder Master Browser gelöst, ergibt sich nach und nach eine immer höhere Grundlast an Broadcasts, die allein dieser Namens- und Adressauflösung dienen. Der Autor konnte in einem Fall beobachten, wie in einem LAN mit rund 500 Stationen und einer durchschittlichen Last von 100 bis 200 Broadcasts je Sekunde in unregelmäßigen Abständen Spitzen von über 1.500 Broadcasts je Sekunde auftraten – weil sich ab und zu im Laufe des Tages die geringfügig unterschiedlichen Broadcast-Intervalle der Windows-Maschinen im selben Zeitpunkt trafen. Dass manchmal Stationen oder Server bei solchen sporadischen Belastungen in den Stillstand verfielen, weil solche Spitzen nicht bewältigt werden konnten (je nach Inhalt auch), war dann schnell erklärt.

Kapitel 11 • Fehler auf dem MAC-Layer

225

11.2.2 Nachweis von Broadcast Storms Der Nachweis ist in aller Regel schnell erbracht, da so gut wie jede NetzwerkManagement-Plattform und so gut wie jeder Analyzer den Wert »Broadcasts/ Second« ausgibt:

Abb. 11.2: LAN-Statistik mit dem Wert für Broadcasts pro Sekunde/Minute

Im Falle der Abbildung 11.2 ist der Fall harmlos; aber das muss ja nicht in jedem Falle so sein bzw. so bleiben. Ansonsten ergibt sich der Nachweis von Broadcast-Stürmen allgemein durch automatische Ausgaben im Ereignisprotokoll der Management-Console:

Abb. 11.3: Typische Ereignisanzeige einer Monitor-Station (LANdecoder32)

Die einzige Form von Broadcast Storm, die vielleicht nicht auf den ersten Blick in ihrer Ursache erkannt wird, ist die fehlerhafte Kennzeichnung normaler LAN Frames als Multicast durch das unerlaubte Setzen des I/G-Bits auf »1« (siehe oben).

226

Spanning Tree Bridges

Die Erkennung eines solchen Szenarios ist dann etwas tricky (und nur dann), wenn der Analyzer in der Darstellung von MAC-Adressen das I/G-Bit ausblendet, also nachträglich in der Darstellung von »1« auf »0« zurücksetzt. Das ist aber nur selten der Fall. Sollte das aber doch einmal der Fall sein, fällt die Lösung am leichtesten, wenn der Analyzer an einem Mirror Port eines Switch angeschlossen ist, der nur die Daten von und zu einem Arbeitsrechner ausgibt: Wenn dann Pakete mit MACAdressen zu sehen sind, die weder Broadcast oder Multicast sind, noch der MACAdresse des gespiegelten Arbeitsrechners entsprechen, ist klar: Das kann nicht richtig sein. Sehr einfach sind Broadcast Storms zu analysieren, wenn der Analyzer anzeigt, dass er viele identische Frames eingelesen hat. Hier sind Beobachtungen auf Layer 2, Layer 3, Layer 4 und Layer 7 sehr wichtig!

11.2.3 Abhilfe bei Broadcast Storms Aus den Fehlerhinweisen ergibt sich im Grunde schon, welche Abhilfe geschaffen, und wie sie geschaffen werden kann. Der aufwendigste Teil der Arbeit ist das Abschaffen von Broadcasts, •

die zur Namens- und Adressauflösung gesendet werden, sofern nicht bereits mit DHCP gearbeitet wird;

•

die als ARBs in stark vermaschten Token-Ring-Netzen gesendet und sodann vervielfältigt werden.

Ansonsten beschränkt sich die Abhilfe technisch lediglich auf das Austauschen von defekten Komponenten. Um die Kosten gering zu halten, ist wichtig, durch Stichproben neue Komponenten in den ersten Wochen und Monaten ständig abzutesten, damit Fehler dieser Art noch während der Gewährleistungsfrist bemängelt werden können.

11.3

Spanning Tree Bridges Bei Bridges und Switches, die nach dem Standard IEEE 802.1d arbeiten und den sog. Spanning Tree Algorithm verwenden, können durch falsche Einstellungen zu ungewünschten oder fehlerhaften Reaktionen verleitet werden. Spanning Tree Bridges werden auch Transparent Bridges genannt, da das Geschehen für die LAN-Adapter der angeschlossenen Stationen unsichtbar ist. Zunächst soll der Aufbau der BPDU (Bridge Protocol Data Unit) erläutert werden, mit welcher sich die Brücken unterhalten:

Kapitel 11 • Fehler auf dem MAC-Layer

227

11.3.1 Die Spanning Tree BPDU Der BPDU-Header hat folgenden Aufbau:

Abb. 11.4: Der BPDU-Header (PCI)

BPDUs werden zwischen Transparent Bridges ausgetauscht, die mit dem Spanning Tree Algorithm arbeiten. Es gibt zwei Varianten der BPDU: •

Configuration BPDU

•

Topology Change Notification BPDU

Hier dargestellt ist die Konfigurations-BPDU; der zweite BPDU-Typ Topology Change Notification BPDU ist nur 4 Byte lang und endet mit dem dritten Feld BPDU Type. BPDUs werden im Ethernet sämtlich an eine vorgeschriebene Funktionsadresse gesendet: 0180C2-000000.

228

Spanning Tree Bridges

Abb. 11.5: Die BPDU in der Darstellung des Analyzers (LANdecoder32)

Die einzelnen Parameter seien genauer erklärt: BPDU Parameter

Länge

Bedeutung

BPDU Protocol ID

2 Byte

Kennzeichnung der aktuellen Protokollvariante. Für Spanning Tree wurde festgelegt: 0x0000.

BPDU Protocol Version ID

1 Byte

Kennzeichnung der aktuellen Protokollversion. Gibt die Versionsnummer des verwendeten Protokolles an. Für Spanning Tree wurde festgelegt: 0x00.

Tab. 11.1: BPDU – Übersicht zu den Parametern des Protokoll-Headers

Kapitel 11 • Fehler auf dem MAC-Layer

229

BPDU Parameter

Länge

Bedeutung

BPDU Type

1 Byte

Kennung des verwendeten BPDU-Typs. Gibt die Art der Meldung an. Für die zwei verschiedenen BPDU-Typen wurde festgelegt: 0x00 = Configuration BPDU 0x01 = Topology Change Notification BPDU Ein ordnendes Verhältnis zwischen BPDUs verschiedenen Typs wird über diese Kennungen nicht hergestellt.

BPDU Flags

1 Byte

Anzeige von Topologieänderungen. Mit diesem Flag werden bei einer Topologieänderung die Inhalte der BPDU angezeigt. Festgelegt wurden bisher: 00000001 Dieses Flag wird von einer designierten Bridge zur Bestätigung einer Topology Change Notification BPDU eingesetzt. An diesem Parameter erkennt die Root Bridge, dass sich die Topologie geändert hat. 10000000 Dieses Flag signalisiert einer Empfänger-Bridge, dass die in der BPDU enthaltene neue Topologieangabe abgespeichert werden muss.

BPDU Root ID

8 Byte

Kennung der Root Bridge. Hier wird die eindeutige Kennung der Root Bridge mitgeteilt. Jede Brücke wird konfiguriert mit einem Priority-Wert (2 Oktette) und einer Bridge ID (6 Oktette). Der Priority-Anteil ist der numerisch höherwertige Teil (most significant). Der 8 Oktette lange Wert der Root ID besteht also aus dem Priority-Wert gefolgt von der Root Bridge ID.

BPDU Root Path Cost

4 Byte

Entspricht in etwa einem Bridge Hop Count. Gibt die aktuellen Wegekosten eines Paketes zur Root Bridge an. Brücken verwenden diese Angabe(n), um den günstigsten Weg zur Root Bridge zu finden. An jeder Brücke kann jeweils ein eigener Cost-Wert eingestellt werden; hierdurch kann Verkehrslenkung betrieben werden. Der Wert Cost beschreibt, wie »teuer« in BPDU-Knoten in der Topology-Berechnung sein soll. Eine Brücke z.B. mit einem Cost-Wert von 5 ließe den Weg zur Root Bridge allen anderen, weiter entfernt liegenden Brücken so erscheinen, als sei nicht eine Brücke, sondern als wären fünf Brücken (mit je Cost=1) dazwischen.

Tab. 11.1: BPDU – Übersicht zu den Parametern des Protokoll-Headers

230

Spanning Tree Bridges

BPDU Parameter

Länge

Bedeutung

BPDU Bridge ID

8 Byte

Eindeutige Bridge-Kennung. Die Bridge-Kennung setzt sich zusammen aus der MAC Adress des Bridge Ports mit der niedrigsten Port ID sowie dem Wert der Bridge Priority. Anhand dieser Bridge IDs ermitteln die aktiven Brücken den günstigsten Weg zur Root Bridge; Bridge Ports mit ungünstigen Wegen werden passiv geschaltet. Die Bridge ID kennzeichnet die Brücke, welche die vorliegende Bridge PDU gesendet hat.

BPDU Port ID

2 Byte

Eindeutige Bridge-Port-Kennung. Jeder Brückeneingang/-ausgang verfügt über eine (für nur diese Bridge) eindeutige und einmalige 2-ByteKennung. Der Wert »0« wird nicht verwendet. Die Konfigurations-BPDUs versenden diese Kennung als Absenderangabe. Das erste Oktett (most significant) ist ein konfigurierbarer Prioritätswert. Das zweite Oktett enthält einen Wert, der von der Bridge dem Port zugewiesen wird, der die BPDU versendet.

BPDU Message Age

2 Byte

Laufzeit der BPDU von Root Bridge zu EmpfängerBridge. Der Wert stellt das Alter der BPDUs dar bzw. die Zeit, die sie von der Root Bridge bis zur empfangenden Bridge benötigte. Das BPDU-Alter ist geschätzt in 1/256-Teilen einer Sekunde seit Absendung durch die Root Bridge.

BPDU Maximum Age

2 Byte

Laufzeit-Grundwert. Enthält einen von der Root Bridge gesetzten, immer gleich bleibenden Wert. Anhand dieses Wertes können die Brücken das Alter einer BPDU berechnen. Der Wert rechnet in 1/256-Teilen einer Sekunde; nach Verstreichen der gesetzten Zeit sollte die Nachricht verworfen werden.

BPDU Hello Time

2 Byte

Zeitlicher Abstand der BPDU-Meldungen. Der Wert gibt das Zeitintervall an, innerhalb dessen sich die Root Bridge regelmäßig über BPDU bei den anderen Brücken meldet. Das Zeitintervall wird in 1/256-Sekundenteilen angegeben.

Tab. 11.1: BPDU – Übersicht zu den Parametern des Protokoll-Headers

Kapitel 11 • Fehler auf dem MAC-Layer

231

BPDU Parameter

Länge

Bedeutung

BPDU Forward Delay

2 Byte

Wartezeit, bevor umgeschaltet wird. Hier teilt die Root Bridge ihren eigenen ForwardDelay-Wert mit, auf den sich dann die anderen Brücken einheitlich einstellen. Der Forward-Delay-Wert wird in 1/256-Teilen einer Sekunde angegeben; er zeigt an, wie lange die Brücken warten sollen, um den Zustand eines Ports von »blocking« zu »forwarding« zu wechseln, um damit die Ersatzwege zu öffnen.

Tab. 11.1: BPDU – Übersicht zu den Parametern des Protokoll-Headers

Durch falsche bzw. ungünstige Konfiguration der Bridges und Switches können negative Effekte eintreten.

11.3.2 Bridge ID/Bridge Priority Bei Spanning Tree Bridges bzw. Transparent Bridges wird in jeder Brücke ein Abbild der aktuellen LAN-Topologie unter Einschluss aller Transparent Bridges hergestellt. Hierzu senden sich die Brücken per BPDU (Bridge Protocol Data Unit) Nachrichten über ihre Konfiguration und über ihren Betriebszustand zu. Das Szenario Um die Eindeutigkeit und damit das Funktionieren der mit Spanning Tree angestrebten Redundanz der LAN-Wege zu erreichen, müssen folgende Werte immer eindeutig sein: •

Bridge ID

•

Bridge Priority (als Teil der Bridge ID)

•

Root ID

Diese Werte werden lokal an der Brücke konfiguriert; die Kennung der sog. Root Bridge ergibt sich aus den umlaufenden BPDU-Nachrichten. Das gesamte Abbild der LAN-Topologie benötigt einen Wurzelpunkt, ab dem die LAN-Topologie logisch erfasst wird – daher auch der Name »Spanning Tree«. Dieser Wurzelpunkt ist immer die sog. Root Bridge, die sich dadurch auszeichnet, dass sie von allen Brücken den numerisch kleinsten Zahlenwert für den Parameter »Bridge Priority« hat und dadurch mit der faktisch höchsten Priorität ausgestattet ist, als Root Bridge zu arbeiten. Die eindeutige Kennung einer Root Bridge ist ein Priority-Wert von »0«.

232

Spanning Tree Bridges

Haben zwei Brücken denselben Wert in ihrer Bridge Priority, und ist dies zufällig der numerisch geringste Wert aller Brücken überhaupt, so gibt es zwei Root Bridges – was der Spanning Tree Algorithm nicht erlaubt und womit er auch nicht umgehen kann. Mögliche Fehlerquellen Viele Brücken – und Switches gehören zur Familie der Brücken! – werden seitens des Herstellers ab Werk sämtlich mit demselben Prioritätswert ausgeliefert – mit der Folge, dass bei Einbau dieser Bridges/Switches sich alle gegenseitig als Root Bridge ansehen. In einem solchen Falle ist es ein Glücksspiel, ob bei einem Leitungs- oder Bridge/ Switch-Ausfall noch die gewünschte Redundanz automatisch zur korrekten Rekonfiguration der Geräte und damit der Verkehrswege eintritt. Vorgehensweisen Es dürfen niemals Brücken oder Switches in Betrieb genommen werden, ohne dass ihre Spanning-Tree-Konfiguration geprüft wurde. Cisco/ISL und HSRP In einigen LANs mit Cisco-Komponenten spielt Spanning Tree keine Rolle mehr, da dort mit den Cisco-eigenen Protokolle ISL (Inter-Switch Link) und HSRP (Hot Standby Router Protocol) gearbeitet wird. Andere Hersteller überlegen, den Spanning-Tree-Standard 802.1d zu erweitern, um neue Funktionalität zu gewinnen.

11.3.3 Nachweis von Spanning-Tree-Fehlern Über das bereits in den vorangegangenen Abschnitten Gesagte hinaus kann leider nur darauf hingewiesen werden, dass nur eine manuelle Durchsicht der verschiedenen BPDUs bei Stichproben hilft. Hierbei aber muss eine bestimmte Vorgehensweise eingehalten werden. Filter auf BPDU Zunächst einmal muss ein Filter auf die BPDUs gesetzt werden, um schnell und übersichtlich durchblicken zu können.

Kapitel 11 • Fehler auf dem MAC-Layer

233

Hierzu gibt es zwei Möglichkeiten. Erstens: Ein vordefinierter Filter in der Software:

Abb. 11.6: Vordefinierter Filter auf BPDU

Zweitens: Ein Filter auf die LLC-SAPs 0x42: Filter auf (Protokoll-Feld/Parameter) ...

Offset

Wert (hex)

LLC: [DSAP]+[SSAP]

14

4242

LLC: [DSAP]+[SSAP]+[Control (UI)]

14

424203

Tab. 11.2: Filter auf LLC-SAPs 0x4242

Abb. 11.7: Manueller Offset-Filter auf LLC und die BPDU-SAPs 0x42 (A)

234

Spanning Tree Bridges

Abb. 11.8: Manueller Offset-Filter auf LLC und die BPDU-SAPs 0x42 (B)

11.3.4 Spanning Tree Timer Das Szenario Wenn auf kurze Umschaltzeiten im Falle einer LAN-Störung Wert gelegt wird, ist unbedingt wichtig, dass alle Brücken möglichst kleine Werte für folgende Parameter aufweisen: •

Hello Time

•

Forward Delay

Sind die Hello-Timer zu hoch angesetzt, also etwa 30 oder 60 Sekunden, so würde eine Brücke den »Ernstfall« möglicherweise erst nach Ablauf einer ganzen Minute erkennen (59 Sekunden), wenn die Störung eintrat, kurz nachdem sie die letzte BPDU der Nachbar-Brücke/des Nachbar-Switches erhalten hat.

Kapitel 11 • Fehler auf dem MAC-Layer

235

Das wäre unvertretbar lang. Ähnlich verhält es sich mit dem Forward-Delay-Timer: Was nutzt es, wenn zwar durch kurze Hello-Timer das Ausbleiben der BPDU vom Nachbarn schnell erkannt wird, dann aber eine lange Umschaltzeit zu Schaden führt? Empfohlene Einstellungen Darum sollte ein Wert gewählt werden, der unter 10 Sekunden liegt.

11.4

Die Bedeutung der Analyse auf Schicht 2–7 Im Kapitel 3 »Grundlagen der Methodik« wurde bereits ausführlich beschrieben, dass sich das Erkennen von Fehlern einer tieferen Schicht oft durch die Analyse einer höheren Schicht ergibt. Wesentlich ist hier auf zwei Bereiche abzuheben: 1. Data Flow Control/Datenflusskontrolle Es wird bei Protokollen, die mit eindeutigen Paketnummerierungen arbeiten, sofort klar, dass Pakete doppelt sind, wenn hierauf geachtet wird. Dies ist vor allem der Fall bei (mit Angabe des OSI Layers): LLC-2 (L2), TCP (L4), SPX (L4), NCP (L7), SMB (L7). 2. IP Fragment ID/IP TTL Bei IP kommt als Hilfe in der Erkennung noch hinzu, dass Pakete auffallen, welche dieselbe (= identische) Paketnummer aufweisen, die sog. IP [Fragment] ID (die eigentliche Bezeichnung ist »IP Identifier«, aber die Bezeichnung »IP Fragmentation ID« hat sich eingebürgert). Da dies jedoch im Zuge eines anderen Fehlers, nämlich des sog. Local Loop oder Local Routing auch vorkommen kann (siehe Kapitel zu TCP/IP), muss zur Erkennung von Paketvervielfältigungen noch derselbe (= identische) Wert für das IP Time-To-Live (TTL) hinzukommen. Sind also bei auffallend vielen IP-Paketen die Werte für IP [Fragment] ID und IP TTL identisch, muss von einer fehlerhaften Vervielfältigung der Pakete ausgegangen werden.

Kapitel 12 Ethernet 12.1 12.2 12.3 12.4 12.5 12.6 12.7 12.8

Einführung Vorgehensweise Physical Layer: die Ethernet-Hardware Ethernet Collisions – CSMA/CD Eingrenzung physikalischer Fehler Ethernet Frame-Typen Bridges/Switches, Spanning Tree & BPDU Ethernet Multicast Addresses

238 241 242 244 254 257 266 268

238

12.1

Einführung

Einführung

12.1.1 Ethernet und Physical Layer Ethernet-Analyse zielt stark auf die Suche nach Fehlern in der Netzwerkphysik (Physical Layer). Hierzu benötigen wir einen Analyzer, •

der uns die Datenpakete verlustfrei von der Leitung holt; dies können nur Analyzer sein, die unmittelbar über die Hardware arbeiten;

•

der uns ein möglichst großes Zeitfenster bietet;

•

der das Setzen möglichst genauer Filter erlaubt.

Bei aller Skepsis, die im Kapitel über Analyzer dem Online-Filtering entgegen gebracht wurde, sollte doch festgestellt werden, dass sich Analyse im Physical Layer (Schicht 1 im OSI-Referenz-Modell) von der Analyse in höheren Schichten unterscheidet. Die Zahl der Möglichkeiten von Auffälligkeiten ist eher begrenzt. Gemessen an der praktisch unendlichen Zahl von Fehlern allein schon auf der Schicht 7 ist das Fehlerrepertoire von Adaptern, Steckern, Buchsen, Kabeln doch eher übersichtlich. Das erlaubt eher schon mal mit Filtern zu arbeiten, um gezielt nach bestimmten physikalischen Fehlern zu suchen, wie sie für die gegebene Netzwerk-Hardware typisch ist. Ein Ethernet mit Koax-Kabeln kennt eben andere Fehler als ein Ethernet mit Twisted-Pair-Kabeln oder Lichtwellenleitern. Entsprechend kann man sich darauf einrichten. Bei der Wahl des Analyzers gilt für den Autor, dass er bei 10-Mbps-Ethernet sogar gelegentlich noch auf einen DOS-Analyzer zurückgreift (LANdecoder/e von Triticom), da dieser in der Lage ist, •

Laufzeitüberschreitungen (oft: Segmentüberlängen) zu erkennen;

•

Fehler von Koax-Kabeln exakt zu bestimmen, da er in der Lage ist, physikalische Fehler als Teil (oder eben nicht Teil) von Kollisionen auszuweisen, was wichtig ist, um Kabelfehler möglichst schnell diagnostizieren zu können.

Aber das ist weitgehend Vergangenheit. Mit einem Analysator, der die bereits entwickelten Kriterien erfüllt, sind die Aussichten auf eine erfolgreiche Messung bestens gegeben.

Kapitel 12 • Ethernet

239

12.1.2 Der Ethernet-Frame Zu Beginn müssen wir uns den Aufbau des Ethernet-Frames verdeutlichen. Die eigentlich zu übertragenden Daten, etwa ein IP-Paket, werden von einem Ethernet-Kopf (Header) und Ethernet-Abschluss (Trailer) umrahmt – daher auch das Wort Frame (Rahmen).

Abb. 12.1: Der Ethernet Frame-Aufbau (Header, Trailer/PCI)

Die folgende Tabelle führt die Protokollfelder einzeln auf und erläutert sie: Länge

Bedeutung

64 Bit

Präambel (Vorspann), u.a. zur Frequenzaufnahme beim Empfänger (Takt-Synchronisation)

6 Oktett

Destination Address/Empfängeradresse 3 Byte Herstellerkennung 3 Byte Stationskennung des Empfängers

6 Oktett

Source Address/Absenderadresse 3 Byte Herstellerkennung 3 Byte Stationskennung des Absenders

Tab. 12.1: Protokollfelder des Ethernet-Frames

240

Einführung

Länge

Bedeutung

2 Oktett

Ethernet II (alt): Kennung des folgenden Protocols = EtherType IEEE 802.3 (neu): Länge der folgenden Daten (immer mit LLC)

46-1500 Oktett/Byte

Nutzdaten: Protokolle höherer Schichten und Anwendungsdaten (etwa: IP-TCP-Telnet)

4 Oktett

Frame Check Sequence (FCS) mit CRC-Prüfsumme

Tab. 12.1: Protokollfelder des Ethernet-Frames (Forts.)

Die vollständige Beschreibung der Ethernet-PCI (Protocol Control Information) ist auf der beiliegenden CD-ROM dokumentiert oder im Internet zu finden unter: http://www.synapse.de/ban/

12.1.3 Ethernet – keine leichte Sache Als der Autor das erste Mal einen längeren Artikel zur Ethernet-Analyse schrieb (erschienen in: N&C, Heft 1/99), war sein erster Gedanke: Mehr als drei Seiten bringst Du niemals zusammen! Dafür ist Ethernet viel zu simpel! Und als dann fast zwanzig Seiten erreicht waren, war klar: Das wird niemals ohne Kürzung abgedruckt. Das soll sagen: Ethernet wird schnell unterschätzt. Gewiss ist es längst nicht so komplex wie Token-Ring, da die Ethernet-Adapter weitgehend »dumm« sind und schon gar keine eigenen Privatgespräche führen (von-Adapter-zu-Adapter, so zu sagen). Und doch besteht eine große Gefahr darin, zu glauben: »da passiert ja doch nichts« oder ähnlich. Es haben sich auch über Jahre Missverständnisse in die Fachliteratur eingeschlichen. Schon allein um den Mechanismus der Kollisionserkennung ranken sich hartnäckig Gerüchte, die seit vielen Jahren in der Literatur von einem Buch aufs nächste vererbt werden. Auch Ethernet muss in Ruhe betrachtet werden, weil sonst die flüchtige Sicht auf Ereignisse und Messdaten zu falschen Schlüssen führt. Es sei noch einmal an das Strukturprinzip der Protokollanalyse erinnert: Jedes Protokoll einer bestimmten Schicht kommuniziert mit dem entsprechenden Treiber des Kommunikationspartners über Steuerdaten, die PCI (Protocol Control Information) oder schlicht Header (Kopfteil, Vorspann) genannt werden; gemeinsam mit der Datenmenge, welche die höhere Schicht zwecks Übertragung an die tiefere Schicht übergibt und die SDU (Service Data Unit) genannt wird, bildet die PCI die sog. PDU (Protocol Data Unit). Kurz gesagt: SDU+PCI=PDU.

Kapitel 12 • Ethernet

241

Protokollanalyse ist also die Auftrennung des Inhaltes eines Datenpaketes in die verschiedenen Protokoll-Header (PCIs) und Daten (SDUs), jeweils gemeinsam erscheinend als PDU. Das spielt bei Ethernet eine gewisse Rolle.

Abb. 12.2: Das Prinzip von PCI und PDU im OSI-Modell

12.2

Vorgehensweise

12.2.1 Eingrenzung von Ort und Ursache LAN-Analyse ist methodisch gesehen in aller Regel der Ausschluss aller möglicher Fehlerursachen, bis am Ende nur noch eine übrig bleibt: Als Ergebnis erfolgt am Ende die Isolation des Orts des Geschehens und der Ursache des Fehlers durch direkten Beweis (Einschluss-Verfahren) und/oder durch indirekten Beweis (Ausschluss-Verfahren). Eine wesentliche Grundlegung der Methodik wurde bereits geleistet in dem vorigen Kapitel »Der Physical Layer«, dessen Kenntnis hier unbedingt vorausgesetzt werden muss.

242

Physical Layer: die Ethernet-Hardware

Methodisch werden in aller Regel zwei Vorgehensweisen verfolgt: einerseits die Eingrenzung des Ortes (geografisch), anderseits die Eingrenzung des beteiligten Protokoll(stapel)s. Beides wird bei den ersten Messungen gleichzeitig in den Blick genommen.

12.2.2 Ort/Topologie/Protokoll Die drei ersten Fragen zur Eingrenzung des Ortes sind immer: •

Ist es der Server?

•

Ist es der Client (bzw. das Peripheriegerät, z.B. ein Drucker)?

•

Oder ist es das Netzwerk dazwischen – mit der gesamten Hardware: Kabel, Stecker, Buchse, Bridge, Switch, Router?

Es wird auf das Kapitel zur Methodik von Messungen verwiesen, wo die Eingrenzung des Fehlers in der Vorgehensweise beschrieben wird. Dies muss hier als bekannt vorausgesetzt werden.

12.3

Physical Layer: die Ethernet-Hardware Bestätigt sich der Verdacht auf Fehler in der Ethernet-Hardware, muss dies durch Messung bestätigt bzw. ausgeschlossen werden. Über die Technik des Eingrenzens eines Fehlerorts in der Physik wurde in Kapitel »Der Physical Layer« bereits gesprochen. Fehler auf dem Physical Layer können sein: •

Fehler einer Adapterkarte (sei des des Controllers auf Layer 2a, sei es im Transceiver auf Layer 1)

•

Fehler eines Verteilers (eines Repeaters, einer Bridge, eines Switches, eines Routers mit dem jeweiligen LAN-Port)

•

zu viele Kollisionen (nicht jedoch Kollisionen schon an sich!)

•

Kabelfehler bzw. elektrische Störungen (Quetschung, Knick, Kurzschluss, Einstrahlung, Überlänge, Dämpfung)

•

mechanische Fehler im Bereich von Stecker und Buchse (Wackelkontakt, induktive Spannungsaufnahme durch falsche oder fehlende Erdung etc.)

Es gibt Analyzer (z.B. LANdecoder32, Surveyor), die es erlauben, folgende Filter zu setzen: •

nur Frames mit korrekter Prüfsumme

•

nur Frames mit defekter Prüfsumme = CRC Error

•

nur Frames mit korrekter Länge

•

nur Frames mit Unterlänge = Frame Short

•

nur Frames mit Überlänge = Frame Long

Kapitel 12 • Ethernet

Abb. 12.3: Filter auf Ethernet-Pakete mit bestimmten Längen

Abb. 12.4: Filter auf Ethernet-Pakete mit richtiger oder falscher Prüfsumme

243

244

Ethernet Collisions – CSMA/CD

Diese Fähigkeit, Filter auf physikalische Ereignisse bzw. Eigenschaften zu setzen, kann von überragender Bedeutung für das Ergebnis der Messung sein. Tauchen die physikalischen Fehler nur sporadisch und zudem selten auf, so ist eine Langzeitmessung angesagt. Hierzu muss aber der Aufnahmespeicher freigehalten werden vom restlichen Datenverkehr, wenn nicht durch dauerhaftes Schreiben der Messdaten auf die Festplatte eine Endlosmessung möglich ist. Die Folge wäre also im Einzelfall, dass man mit einem Filter arbeitet, der den Analyzer ausschließlich defekte Frames aufnehmen lässt. Es wurde schon zuvor beschrieben, welche Chancen und Risiken bei der Verwendung von Filtern bestehen: Filter verlängern das Zeitfenster der Messung, machen aber eben auch partiell »blind«. Steht beispielsweise zu vermuten, dass eine Komponente auf defekte Frames nervös (also ihrerseits fehlerhaft) reagiert, so müssen alle Daten eingelesen werden, gute wie schlechte. Anders lassen sich Wechselwirkungen messtechnisch nicht nachweisen. Ein entsprechendes Beispiel wurde bereits erwähnt. Sind Fehler in der Physik ausgeschlossen und liegt also der Fehler gewiss auf den höheren Schichten, so ist es durchaus angemessen, die Annahme defekter Frames zu unterbinden. Allerdings dürfte der Effekt dann auch praktisch gleich Null sein – also setzt man einen solchen Filter schon aus Gründen der Vorsicht und der Vollständigkeit der Messdaten nicht.

12.4

Ethernet Collisions – CSMA/CD Nicht alles, was nach »Kollision« aussieht, ist auch eine »echte« Kollision. Daher muss kurz der Kollisionsmechanismus von Ethernet erklärt werden. Alle Kabel eines physikalischen Ethernet-LAN-Segments bilden eine sog. »Ethernet Time Domain« oder »Ethernet Collision Domain«; diese endet jeweils an einer Bridge, einem Switch, einem Router. In dieser Zeitzone (»time domain«) darf jedes Bit maximal nur 25,6 µs auf der Leitung sein (»slot time« = der hierfür erforderliche freie Zeitschlitz). Anders gesagt: Nach 25,6 µs muss jedes Bit das Segment durchlaufen haben und muss an einem Koax-Endwiderstand oder bei einer Twisted-Pair Kabel-Buchse (TP-Port) eines LAN-Adapters, einer Bridge, eines Switches oder eines Routers angelangt sein. Wenn das erste Bit eines Ethernet-Frames diese Zeitzone noch nicht voll durchlaufen hat – und damit korrespondierend noch nicht die gesamte Segmentlänge – , kann so lange noch eine zweite Station im nicht erreichten bzw. durchlaufenen Teil des Segments damit beginnen, ihrerseits zu senden, da ihr »Carrier Sense« (CS, Träger-Prüfung) zutreffend ergibt, dass die Leitung »frei« (»idle«) ist – eine korrekte Annahme, da ja das Signal der ersten Station noch nicht bei der zweiten angelangt ist. Somit ereignet sich in der Folge ein »Multiple Access« (MA, Mehr-

Kapitel 12 • Ethernet

245

fachzugriff), und die Kollision der beiden Signale bzw. Datenpakete ist auf einem Shared Media unvermeidlich. (Nur in einem vollständigen Switched LAN verhindern die Switches diesen Effekt.) Jeder Ethernet-Adapter jedoch, der sendet, »hört« dabei gleichzeitig auf die Leitung und ermittelt via Pegelabgleich, ob das eigene Signal fehlerfrei auf der Leitung ist: Eingangs-Pegel muss gleich Ausgangs-Pegel sein. (Intern findet eine Pegelumkehr des Eingangs-Signals statt; eine Addition von Eingangs- und Ausgangs-Pegel muss dann »0« ergeben.) Schlägt der Pegelabgleich fehl, wird das Vorhandensein eines »Signal Quality Error« (SQE, Signal-Güte-Fehler) angenommen, was zum sofortigen Abbruch der Übertragung der Nutzdaten führt. Entgegen mancher Darstellungen, dass der Eintritt des SQE-Ereignisses zum sofortigen Abbruch sämtlicher Sendetätigkeit führe, muss betont werden: Der Ethernet-Frame selber wird immer komplett gebildet bzw. gesendet einschließlich des 32-Bit-Prüfsummen-Feldes (FCS), in welches immer eine garantiert »falsche« Bit-Sequenz eingetragen wird, die sog. »Jam Sequence« (mehr hierzu: siehe unten). Hierbei handelt es sich gewissermaßen um eine »Dummy CRC«, um sicherzustellen, dass nicht irrtümlich das defekte Paket seitens irgendwelcher Empfänger als korrekt berechnet angesehen wird. Bis jetzt hat aber nur der zweite Sender den SQE entdeckt. Der im zeitlichen Ablauf erste Sender entdeckt die Kollision erst mit einiger Verzögerung gegenüber dem zweiten Sender, sobald das – zerstörte – Signal des zweiten Senders bei ihm anlangt und die eigenen Signale überlagert. Damit beim ersten Sender die »Collision Detection« (CD, Kollisionserkennung) jedoch überhaupt arbeiten und sämtliche Kollisionen zuverlässig erkennen kann, ist erforderlich, dass dieser zum Zeitpunkt des Eintreffens des »gegnerischen« Signals selber noch sendet. Dies führt zwingend zu der Mindest-Paket-Länge bei Ethernet von 64 Byte. Der späteste Zeitpunkt des Auftretens einer Kollision ist nach dem (fast) vollständigen Ablauf von 25,6 µs Sekunden, also sozusagen kurz vorm Anschlag des ersten Bits eines Datenpaketes am Segmentende: Bei nur 2 Bit-Längen Entfernung vom Segmentende (2 x 0,1 µs) kann ein zweiter Adapter noch beginnen zu senden. Diese 25,6 µs entsprechen einer gesendeten Datenmenge von 32 Byte. Da für den Weg des »gegnerischen« Signals ebensfalls max. 32-Byte-Zeiten anfallen (die Zeit, die benötigt wird, um 32 Byte zu senden), kann der erste Sender die Kollision nur dann mit Sicherheit erkennen, wenn er mindestens 64 Byte lang sendet: Über die Sendezeit der ersten 32 Byte der ersten Station geschah nichts; exakt mit Erreichen des 32. Byte kann gerade noch (als letztem Zeitpunkt) die Kollision am fernen Kabelende eintreten; dann braucht es wieder die Sendezeit von weiteren 32 Byte, bis das erste Bit des zweiten Senders beim ersten Sender eintrifft.

246

Ethernet Collisions – CSMA/CD

Wird das Verhältnis von Slot Time = 25,6 µs zu Kabellänge durchbrochen, können sog. Late Collisions die Folge sein (Laufzeitüberschreitungen wegen Segmentlängenüberschreitungen, s.u.). Beide Kollisionsteilnehmer treten im Kollisionsfalle in einen Wartezyklus, der aufgrund eines Zufalls-Algorithmus’ nur selten bei allen Kollisionsteilnehmern zu identischen Wartezeiten führt (»truncated binary backoff timer«). Nach Ablauf dieser Wartezeit beginnt der Sendezyklus von CSMA/CD erneut. Sollten 16 Sendeversuche eines Adapters in Folge in Kollisionen bzw. mit SQE enden, meldet der Transceiver »Carrier Lost« (Medium nicht mehr verfügbar).

12.4.1 »Carrier Lost« Tritt ein »Carrier lost«-Ereignis bei einem Repeater ein, so schließt er den entsprechenden Port (»Auto-Partitioning«) und öffnet ihn erst wieder, wenn es der Zustand auf dem Kabel wieder erlaubt (»Re-Connection«). Bei LAN-Adaptern ist nicht sicher, dass sie nach Eintreten des »Carrier Lost«Zustandes jemals wieder die Sende- und Empfangstätigkeit aufnehmen; hier haben sich die Hersteller in der Vergangenheit oft unterschiedlich entschieden. Es kann also sein, dass ein Ethernet-Adapter defekt erscheint, obwohl er »nur« nach einem »Carrier Lost«-Ereignis stumm blieb und sich infolgedessen manche Netzwerkapplikation »aufgehängt« hat – oder gleich der ganze Rechner. Insbesondere ältere Adapter und Betriebssysteme können derart reagieren. Neuere Produkte versuchen diesen Fall fehlertolerant abzufangen und nach einer Wartezeit den Zugriff aufs Medium erneut zu erreichen. Signalfehler bzw. Kollisionen werden schon im Ethernet-Adapter (im Transceiver) erkannt; die entsprechenden Fehlerzähler werden lediglich an die darüber arbeitende Analyse-Software gemeldet/durchgereicht bzw. von dieser abgefragt.

12.4.2 »Late Collisions« Sind die Kabelwege länger, als das Signal in 25,6 µs Slot Time durchlaufen kann, können sog. Late Collisions auftreten. Erreicht das erste Bit nach Ablauf der maximalen Laufzeit von 25,6 µs die höchstzulässige Segmentlänge, ohne dass das Kabel tatsächlich endet, so verbleibt noch eine restliche Kabellänge, die durch das Signal noch nicht belegt ist, und die als Segmentüberlänge bezeichnet wird. Das Ergebnis ist eine Laufzeitüberschreitung. Ist in dieser Segmentüberlänge ein sendebereiter Ethernet-Adapter angeschlossen, so ergibt dessen Carrier Sense (CS) subjektiv: »Leitung frei«. In der Folge gibt es Multiple Access (s.o.) und Kollisionen bzw. SQE, die jedoch beim zeitlich gesehen ersten Sender nicht mehr zuverlässig erkannt werden können. Überträgt der Erst-Sender nur Pakete der Mindestlänge von 64 Byte, so kann er den Verlust

Kapitel 12 • Ethernet

247

seines Paketes durch Pegelabgleich nicht mehr erkennen, da das »gegnerische« Signal erst nach Ablauf der 64-Byte-Zeiten ankommt. Die Folge dieses Nicht-Erkennens eines SQE im eigenen Paket durch die Ethernet-Adapter-Hardware führt dazu, dass erst in höheren Treiberschichten (z.B. TCP) erkannt werden kann, dass die Übertragung wiederholt werden muss. Da die Warteschleifen (»timer«) in den Protokollen höherer Schichten aber deutlich länger laufen als der »Truncated Binary Backoff Timer« bei Ethernet, bedeuten zahlreiche Late Collisions einen erheblichen Zeitverzug, der beim Anwender zur Aussage führt: »Das Netzwerk ist langsam.« Denn tatsächlich summieren sich dann viele (gar nicht so) kleine Wartezeiten zu spürbar verlängerten Antwortzeiten auf. Late Collisions können messtechnisch wie folgt nachgewiesen werden: Am äußersten Ende eines Ethernet-Segments (Koax, TP) wird der Analyzer angeschlossen, der nunmehr regelmäßig Ethernet-Frames sendet, und zwar mit deutlich mehr als 64 Byte; am besten mit der maximalen Paketgröße von 1.518 Byte. Jedes zusätzliche, über 64 Byte hinausgehende Byte erlaubt (bei 10 Mbps Ethernet) das Austesten weiterer 160 Meter möglicher Segmentüberlänge. (Jedes Bit ist bei 10-Mbps-Ethernet auf dem Koax-Kabel ca. 20 Meter »lang«). Wenn der Analyzer nach bereits erfolgter Übertragung des 64. Bytes einen SQE (Signal Quality Error) erkennt bzw. der Pegelabgleich nicht »sauber« ist, so ist die Ursache hierfür eine Late Collision – allerdings nur unter Voraussetzung einwandfreier Kabel-Physik, weil Kabelfehler ähnliche Erscheinungen hervorbringen können (s.u., »Phantom Collisions«). Jeder Ethernet-Adapter kann Late Collisions erkennen, sofern er lang genug sendet, also das aktuelle Datenpaket lang genug ist, um darin noch den SQE zu erkennen (also größer 64 Bytes). Entsprechend wird bei erkannter Late Collision auch korrekt die vorgesehene Fehlerroutine eingeleitet. Leider gibt es hierüber falsche Aussagen in den einschlägigen Ethernet-Büchern. Ein solcher Late-Collision-Test hat jedoch nur regelmäßig Aussicht auf Erfolg, wenn er einen oder mehrere Tage hindurch non-stop läuft. Schließlich kann nicht davon ausgegangen werden, dass Ethernet-Adapter, die in Überlängesegmenten angeschlossen sind, auch an jedem Tag und zu jeder Zeit senden. Hier ist auf Urlaubszeiten und Gleitzeit-Regelungen Rücksicht zu nehmen. Software-Analyzer, die über NDIS- oder ODI-Treiber arbeiten, sind regelmäßig nicht in der Lage, solche Tests durchzuführen. Dies gelingt zuverlässig nur Analyzern, die direkten Zugriff auf den Chipsatz des Adapters haben: Dies sind die sog. Hardware-Analyzer sowie die Software-Analyzer des Herstellers Triticom, dessen LANdecoder direkt auf die Ethernet-Adapter zugreifen kann (»AccuCapture«, »Direct Drivers«).

248

Ethernet Collisions – CSMA/CD

12.4.3 »Phantom Collisions« Nicht alles, was als »Collision« gemeldet wird, ist auch eine echte Kollision. Kollisionen sind dann echt, wenn die Ethernet-Frames von zwei oder mehr Adaptern sich überlagern. Als »Collision« werden jedoch jegliche SQEs (Signal Quality Errors) gemeldet, die durch das Mittel des Pegelabgleichs erkannt werden können. Daraus folgt, dass die Meldung »Collision« nicht zwingend auf den Multiple Access mehrerer Ethernet-Adapter zurückgeführt werden kann. Andere Ursachen eines SQE können Störstrahlungen sein, die vom Kabel induktiv aufgenommen werden, oder Reflexionen des Ethernet-Signals, bewirkt insbesondere durch Kabelfehler (Kurzschluss, Wackelkontakt). Auch Ausgleichsströme, die durch falsche Erdung und den daraus folgenden Kapazitätsaufbau an einem der beiden Kabelenden verursacht werden, können als Kollision gedeutet werden. Besonders anfällig für solche Erscheinungen ist das Koax-Kabel (das wegen seiner Fehleranfälligkeit schon als »Fehler-an-sich« bezeichnet werden könnte!). Unzweifelhaft kollidiert in jedem dieser Fälle das Signal des sendenden EthernetAdapters mit einem zweiten »Signal«; dieses aber ist in den genannten Fällen eben kein reguläres Ethernet-Signal, sondern ein Störsignal aufgrund eines Fehlers. Wie ist nun messtechnisch zu unterscheiden, ob »echte« oder »unechte« Kollisionen vorliegen? Treten »Collisions« auf bei signifikant niedriger Datenrate (Paketrate, Netzlast), ist dies ein möglicher Hinweis auf Phantomkollisionen. Lässt sich der Ort der Kollision bestimmen und bleibt dieser Ort immer identisch, so spricht auch das für Phantomkollisionen. Dies führt zu weiteren Fragen: Welche Netzlast steht im Zusammenhang mit Kollisionen? Wie grenze ich den Ort von Kollisionen ein?

12.4.4 »Local Collisions« vs. »Remote Collisions« Ein sendender Ethernet-Adapter erkennt via Pegelabgleich den SQE (Signal Quality Error) und somit die Kollision (sofern keine Late Collisions erfolgen). Ein Analyzer, der passiv Ethernet-Frames aufnimmt, kann naturgemäß keinen Pegelabgleich durchführen. Woran also erkennt der LAN-Analysator dann aber eine Kollision? Jeder Ethernet-Adapter (nicht nur der eines Analyzers) prüft die Signalqualität mittels SQE-Test. Werden irreguläre Frequenzmuster und/oder Pegelwerte erkannt (allesamt die unweigerliche Folge einer Signalüberlagerung), so wird das Paket korrekt als »defekt« erkannt. Der Adapter hat damit den SQE ermittelt.

Kapitel 12 • Ethernet

249

Dieses Szenario wird als »Local Collision« bezeichnet: Der Ethernet-Transceiver erkennt selber den SQE und somit auch die Kollision. Diese Erkennung kann nur erfolgen, weil sich die Kollision tatsächlich unmittelbar am Transceiver ereignet. Gänzlich anders ist es, wenn die Kollision sich jenseits eines Repeaters ereignet und damit »Remote Collision« genannt wird. (Achtung: Bridges, Switches, Router geben keine Kollisionssignale weiter!) Der Eingangs-Port (Rx) eines jeden Repeaters hat die Aufgabe, die analogen Signale in binary digits (Bit) zurückzuwandeln (A/D-Wandler: analog-zu-digital). Die einzigen binary digits, die erkannt werden können, sind »0« und »1«. Empfängt der Rx-Port des Repeaters jedoch irreguläre Frequenzmuster und/oder irreguläre Pegelwerte, so ist die Umwandlung in »0« und »1« nicht [mehr] möglich. Da der Repeater jedoch zwingend das Signal (genauer: irgendein Signal) auf den Ausgangs-Ports (Tx) ausgeben muss (genauer: auf allen seinen anderen Ports), ersetzt er die unleserlichen Signale durch willkürliche Folgen von »0101« bzw. »1010«, bis ggf. wieder ein reguläres Ethernet-Signal empfangen werden kann. Das entsprechende physikalische Codierungsmuster heißt bei 10-Mbps-Ethernet »Manchester Code«, bei 100-Mbps-Ethernet (Fast Ethernet) »8B6T«. Diese sog. »Stopf-Bits« ergeben in ihrem Muster in der hexadezimalen Darstellung des LAN-Analysators folgende Bilder (bzw. willkürlich durchwürfelte Versatzstücke daraus): Hex-Darstellung

Binäre Bit-Folge

AAAAAAAA =

1010101010101010

55555555 =

0101010101010101

A5A5A5A5 =

1010010110100101

5A5A5A5A =

0101101001011010

Tab. 12.2: Stopf-Bits bzw. Füllmuster von Repeatern bei Kollisionen

Diese Hex-Bytes sind immer ein Anzeichen von »Remote Collisions«, also Kollisionen, die sich jenseits eines Repeaters ereigneten und durch diesen physikalisch »geglättet« wurden: Während vor dem Repeater noch irreguläre Pegelwerte und Fequenzmuster auftreten (»Local Collision«), ist das Physical Coding hinter dem Repeater einwandfrei (»Remote Collision«). Tauchen diese Hex-Muster in den MAC-Adressen auf (Ethernet Destination/ Source Address), so ist zwingend von einer Remote Collision auszugehen. Dies führt bei Koax-Verkabelung durchaus zu verwertbaren Aussagen über den Ort des Geschehens; bei TP-Verkabelung ist praktisch jede Kollision zwingend eine Remote Collision, da jedes Signal stets über Repeater läuft (sei es über einen, sei es über mehrere).

250

Ethernet Collisions – CSMA/CD

Es sei erneut daran erinnert: Bridges, Switches, Router verwerfen Collision Frames – jenseits dieser Geräte also wird nichts sichtbar. Das ist ja u.a. der Sinn ihres Einsatzes: Physikalische Fehler wie Kollisionen werden durch sie räumlich begrenzt. Zurück zu den Stopf-Bits bzw. Füllmustern. Dass es sich hierbei um die Folge von Kollisionen handelt, ist allein menschliche Interpretation; der Analyzer ignoriert diese Stopfmuster eines Repeaters. Er »erkennt« die Remote Collision gänzlich anders, nämlich mittels des gleichzeitigen Auftretens folgender Merkmale: •

Frame Short/less than 64 bytes: Das Paket ist kleiner als vorgeschrieben.

•

CRC Error/invalid Frame Check Sequence: Die Prüfsumme stimmt nicht.

Zur Erinnerung: Erkennt ein Ethernet-Adapter durch Pegelabgleich den SQE, so wird die Übertragung der Nutzdaten abgebrochen; gleichwohl aber werden MACHeader und MAC-Trailer noch korrekt gesendet, wobei im FCS-Feld eine »garantiert falsche« Prüfsumme eingesetzt wird. Diese »garantiert falsche« Prüfsumme wird »Jam Sequence« genannt; man könnte sie auch »Dummy CRC« nennen. Um diese »Jam Sequence« ranken sich in der Literatur die absurdesten Mythen und Legenden. Einzig wahr ist, dass sie der Kollisionserkennung dient – aber nur jenseits eines Repeaters im Falle von Remote Collissions, bei denen kein Pegelabgleich mehr helfen kann, weil das Signal den Repeater in jedem Falle physikalisch »gesund« verlassen hat.

12.4.5 »Runts« Ausnahmen von dieser Regel sind allein dann gegeben, wenn sich am Rx-Port des Repeaters die Kollisionssignale dermaßen überlagern, dass exakt ein Gleichstrom bei mittlerem Voltpegel resultiert, und das über die Dauer = Länge mehrerer Bits. Dies kann durchaus geschehen, wenn sich zwei Signale bei komplementären BitSequenzen exakt gegenseitig auslöschen. Das ist selten, kommt aber vor. Bei diesem Szenario nimmt der Repeater an, es handele sich um eine Sendepause, also um den regulären Abstand zwischen zwei Ethernet-Paketen. Somit entfällt auch das oben genannte Stopfen, und jenseits des Repeaters erscheinen infolgedessen zwei (oder noch mehr) Ethernet-Fragmente, resultierend aus ursprünglich nur einer Kollision. Sind diese »Schnipsel« kürzer als 96 Bit, so füllt sie der Repeater auf die Länge von 96 Bit auf (= 12 Byte). Diese Fragmente werden »Runts« (Krüppel) genannt. Sie bestehen scheinbar nur aus [MAC Destination Address] + [MAC Source Address].

Kapitel 12 • Ethernet

251

Mit dem Fehlen jedes weiteren Bytes und damit auch jeglicher Prüfsumme gehen verschiedene Analyzer übrigens verschieden um, weswegen das Konvertieren zwischen den verschiedenen Trace-Formaten verschiedener Hersteller durchaus nicht unproblematisch ist. Doch zurück zum Thema: Eine schnelle Abfolge von vielen Runts kann zur kurzzeitigen Überlastung des Ethernet-Adapaters im Analyzer führen, da seine Architektur auf eine MindestPaket-Länge von 64 Byte eingerichtet ist, was einer Begrenzung der eingehenden Pakete pro Sekunde gleichkommt. Ereignen sich nun massenhaft Runts, ist eine mögliche Folge, dass Paketverluste (»Frame Loss«) gemeldet werden – obwohl nichts dergleichen tatsächlich geschah. Kommen die Überlastmeldungen des Analyseadapters also während einer Kollision oder während einer ganzen Abfolge von Kollisionen, so sind sie vernachlässigenswert.

12.4.6 »CRC Error« »CRC Errors« werden gemeldet, wenn der 32-Bit-Ausdruck in der sog. Frame Check Sequence im MAC-Trailer keine zutreffende Prüfsumme darstellt; genauer: wenn die letzten 32 Bit des Frames nicht als korrekte Prüfsumme über die vorangegangenen Bytes gedeutet werden können. Hierzu sei bemerkt, dass die tatsächlichen Prüfsummen durchaus länger sind als nur 32 Bit; aber nur die letzten 32 Bit werden beim Absender ins FCS-Feld gelegt. Dies bietet überaus hinreichende Genauigkeit, da sich Bit-Fehler nur mit einer Abweichung von kleiner 10–10 außerhalb dieser 32 Bit niederschlagen. Die Ursachen von CRC-Fehlern können Kollisionen sein (echte oder falsche, s.o.) bzw. Fehler in der Physik (Kabelfehler, Störstrahlungen etc.). Ein übergroßer Anteil von Frames mit CRC-Fehler ist regelmäßig ein Zeichen von übermäßiger Signaldämpfung; dies ist meistens bedingt durch Überlänge der Kabel (ohne Repeater, also ohne Verstärkung), was überwiegend bei unkontrollierter Verlängerung von Koax-Kabeln vorkommt. Bei TP-Verkabelung sind CRC-Fehler außerhalb von Kollisionen eher selten. Jeder Analyzer zeigt CRC-Fehler an, sofern LAN-Adapter und Treiber im Promisuous Mode arbeiten.

12.4.7 »Alignment Error« »Alignment Errors« werden bei Taktverlust = Frequenzverlust seitens des Empfängers gemeldet. Taktverlust kann die Folge von Kollisionen sein, aber auch von Kabelfehlern. Bei TP-Verkabelung äußern sich Drill-Fehler regelmäßig in »Alignment Errors« und zeigen damit eine Störung in der sog. Komplementär-Übertragung an.

252

Ethernet Collisions – CSMA/CD

Twisted-Pair-Kabel schützen die Signale vor Nahnebensprechen/Übersprechen durch die sog. Komplementär-Übertragung: Während für normale elektrische Stromkreise je Übertragungsrichtung eine Ader ausreicht, werden bei TP je Richtung zwei Adern verdrillt (darum auch: »verdrillter Zweidrahtleiter«). Auf der einen Ader wird das eigentliche Signal gesendet, auf der anderen das genaue elektrische Gegenteil (Pegelumkehr). Nach außen hin heben sich die Abstrahlungen gegenseitig auf; hierdurch wird das Übersprechen zwischen Rx- und Tx-Doppelader verhindert. Dieses Verfahren setzt jedoch ein genaues Verhältnis von Drill (= Schlag pro Meter) und verwendeter Frequenz voraus. Wird das Kabel in seinem Drill verändert bzw. wird der Drill verletzt, so geht der Schutz der Komplementär-Übertragung verloren. Diese Drill-Verletzungen und das daraus folgende Signal-Übersprechen äußert sich bei TP-Ethernet (10BaseT, 100BaseTX) regelmäßig (nicht nur, aber vorwiegend) in »Alignment Errors«. Es stellt sich die Frage: Wie kann messtechnisch unterschieden werden zwischen kollisionsbedingten Alignment Errors und allen anderen, die außerhalb von Kollisionen auftreten und damit vermutlich auf Drill-Fehler zurückzuführen sind? Es gibt folgende Möglichkeiten: •

Es wird ein Analyzer verwendet, der dies ausdrücklich ausweist. Hier sei die überaus preiswerte Software EtherVision (Triticom) genannt, deren LogDateien diesbezüglich vollen Aufschluss bieten (nur 10 Mbps).

•

Der Zähler für Alignment Errors wird in ein Verhältnis gesetzt zum Kollisionszähler. Ist die Zahl der Alignment Errors größer als die für Kollisionen, so ist von Kabelfehlern auszugehen.

•

In der Online-Beobachtung ist die Unterscheidung sonst nur möglich durch einen DOS-Analyzer, dessen zeitliche Auflösung in der Darstellung die geforderte Unterscheidung erlaubt. Windows-Analyzer erhöhen ihre Zähler nur 1 x je Sekunde, und dies erlaubt keine Aussage mehr darüber, ob die Erhöhung der Zähler bei »CRC Error«, »Alignment Error« und »Collision« auf dasselbe Ereignis zurückgehen oder nicht, sofern der Kollisionszähler ständig einen größeren Wert aufweist als jeder der beiden anderen Zähler.

Um die Bedeutung gründlicher Beobachtung und Schlussfolgerung zu verdeutlichen, soll ein Beispiel aus der Praxis des Autors angeführt werden: Es wurde eine der vielen Banken im Frankfurter Westend besucht; das LAN (10BaseT) erstreckte sich über viele Etagen eines Hochhauses. Der Analyzer war keine drei Minuten an der Leitung, da sagte ich den verblüfften Kunden auf den Kopf zu:

Kapitel 12 • Ethernet

253

»Sie haben Unshielded Twisted Pair (UTP) verlegt, Sie gehen mit den UTP-Kabel die Steigleitungen hinauf in die höheren Etagen (statt mit LWL), die Kabel sind in ganzen Bündeln aufwärts verlegt und sie sind schon mehrere Jahre alt – viel Spaß bei der Neuverkabelung!« Für einen Moment wurde ich für einen Hexer gehalten – woher konnte ich das alles wissen? Ich erklärte, dass das mit Magie nichts zu tun habe, sondern mit dem simplen Verhältnis der paar Zähler im Analyzer: Wenn rund 30–40% aller Pakete (!!) wegen eines Alignment Errors defekt waren, sich aber gleichzeitig praktisch keine Kollisionen ereigneten, so sei dies das typische Szenario für ein massenhaftes Übersprechen von TP-Leitungen, deren Drill massiv gestört ist. Und da wir uns ersichtlich in einem Hochhaus befänden, sei es nun mal nahe liegend, dass die TP-Kabel bündelweise senkrecht gehängt worden seien bei völlig unzureichender Zugentlastung, was über die Jahre hinweg (so schnell geht das eben auch nicht!) zu einer Auflösung des Drills und somit zu einem Verlust des Schutzes durch die Komplementär-Übertragung geführt habe. Und damit dieses Ereignis zu derart massenhafter Paketzerstörung führen könne, sei nun mal notwendig, (a) dass die Kabel in Bündeln verlegt bzw. verhängt worden seien, und (b) dass es sich dabei um ungeschirmte Kabel handeln müsse. Da das alles nachvollziehbar klang, wurde ich nicht als Zauberer verbrannt und durfte ziemlich schnell wieder nach Hause fahren. Außerdem kaufte der Kunde sofort die Software, die das alles so schön anzeigen konnte (EtherVision, Triticom). Manchmal kann Messtechnik eben wirklich Freude bereiten.

12.4.8 »Frame Short« Ist ein Ethernet-Frame kürzer als die geforderten 64 Byte, wird das Ereignis »Frame Short« genannt. Diese Erscheinung ist bei Kollisionen nicht nur normal, sondern zwingend. (Siehe hierzu den obigen Abschnitt »Ethernet Collisions – CSMA/CD«). Außerhalb von Kollisionen kann dieses Ereignis auf einen defekten Adapter (oder Bridge/Switch/Router-Port) hinweisen, aber auch auf einen Wackelkontakt oder auf sporadisch einwirkende Störstrahlungen. Auch hier gilt, dass messtechnisch gewährleistet sein muss, dass zwischen Frame Short innerhalb von Kollisionen und solchen anderer Art unterschieden werden kann (siehe die vorigen Abschnitte »Runts« und »Alignment Error«). Grundsätzlich gilt: Ist der Zählerstand für Frame Short kleiner als der Zählerstand für Collision, so dürften die Frame-Short-Ereignisse ganz oder überwiegend innerhalb von Kollisionen bzw. als deren Folge entstanden sein.

254

Eingrenzung physikalischer Fehler

Sollte der Zählerstand für Frame Short größer sein als der Zählerstand für Collision, muss von Fremdeinflüssen ausgegangen werden, etwa einwirkenden Störstrahlungen, Kriechströmen oder Kabelfehlern. Eine besondere Situation kann bei Switches vorliegen, die bei Buffer Overflow den angeschlossenen Adaptern mit künstlichen Kollisionsmeldungen signalisieren, dass zur Zeit keine Übertragungen möglich sind.

12.4.9 »Frame Long«/»Jabber« Ist ein Ethernet-Frame länger als die erlaubten 1.518 Byte (18 Byte Ethernet Header+Trailer, max. 1.500 Byte Daten), so wird gemeldet: »Frame Long«. Dieses Ereignis ist heute nur selten zu beobachten und ist zudem dann meist die zufällige Folge einer Kollision, sofern die Überlänge nur wenige Bytes beträgt. In den 80er Jahren kam es schon mal vor, dass ein defekter Adapter gar nicht mehr aufhören wollte zu senden. Dies wurde dann als »Jabber« bezeichnet: Der Adapter hörte eben nicht mehr auf, vor sich hin zu »plappern«. Der Autor hat ein einziges Mal einen solchen »Jabber« beobachtet, als ein Ethernet-PCI-Adapter sich nicht mit dem Video-Adapter vertrug und bis zu 65.535 große Frames verschickte. Dieses Ereignis ist wegen seiner Seltenheit geradezu museumsreif. Überlange Frames mit Längen von einigen Tausend Bytes dagegen können durchaus das eine oder andere Mal auch außerhalb von Kollisionen beobachtet werden. Im Jahre 1999 war das gleich mehrfach der Fall, und jedes Mal waren es defekte Switches eines bestimmten Herstellers, der in seiner Hardware zufällig einen solchen Fehler eingebaut hatte.

12.5

Eingrenzung physikalischer Fehler Sind physikalische Fehler nachgewiesen, muss festgestellt werden, woher der Fehler rührt: Es muss das Kabelsegment identifiziert werden, in dem (auf dem) sich der Fehler ereignet. Es geht die Mär, dass Kabelfehler mit dem Kabeltester zu suchen und zu finden wären. Dies ist von Grund auf falsch. Die Arbeit mit Kabeltestern hat folgende Nachteile: Viele Tests können nur durchgeführt werden, wenn die Kabel aus dem Verkehr genommen wurden. Dies macht viel Arbeit, wenn der Ort ungewiss ist, und verärgert entweder die Anwender, weil sie in ihrer Arbeit unterbrochen werden, oder die Techniker, weil sie abends Überstunden schieben müssen. Außerdem erlaubt jeder Test nur eine Aussage über jeweils nur genau ein Kabel; für ein dermaßen begrenztes Ergebnis ist der Aufwand jedoch viel zu groß.

Kapitel 12 • Ethernet

255

Manche Fehler ereignen sich zudem nur bei laufendem Datenverkehr (und auch dann nur sporadisch). Hier sind Messungen, die ein passives Kabel verlangen, vollkommen ungeeignet – und somit auch der Kabeltester. Manche Fehler ereignen sich zudem dermaßen selten, dass Langzeitmessungen nötig sind. Auch hierfür sind Kabeltester vollkommen ungeeignet. Kabeltester geben keine Chance, Wechselwirkungen zwischen Ereignissen verschiedener Komponenten und Protokolle zu erkennen. Eine genaue Ausführung hierzu ist im Kapitel »Physikal Layer« enthalten. Die Alternative zum Kabeltester lautet daher zwingend: Da jeder physikalische Fehler seinen eigenen, ihm typischen »Fingerabdruck« im Datenpaket hinterlässt, reicht es vollauf, mit dem PC-Analyzer den Datenverkehr zu verfolgen. Bei einiger Kenntnis der verwendeten physikalischen Codierung (z.B. Manchester Code bei 10-Mbps-Ethernet) können die Fehlermeldungen bei Ethernet hinreichend genau den möglichen Ursachen zugeordnet werden.

Abb. 12.5: Das Signalmuster beim Manchester Code (10Base5, 10Base2, 10BaseT)

Bei der Fehlersuche mittels LAN-Analysator muss Folgendes berücksichtigt werden: Handelt es sich um ein 100-prozentiges Switched Network, so ist ein physikalischer Fehler von vornherein eingegrenzt über das übliche SNMP-Management erkennbar. Handelt es sich – wenigstens teilweise – um Shared Media Segments (Repeater statt Switches), so sind der Fehler und seine Diagnose gleichzeitig bedingt: Nur in

256

Eingrenzung physikalischer Fehler

einem Shared Media Segment stellt sich die Frage nach dem Ort; gleichzeitig aber bietet das Shared Media Segment auch die Bedingung für die messtechnische Eingrenzung des Fehlerortes. Unter der Voraussetzung, dass der Netzwerkdokumentation zu entnehmen ist, welcher Ethernet-Adapter wo angeschlossen ist (sei es am Koax-Kabel, sei es via TP am Repeater-Port), so ist wie folgt zu verfahren: Man hänge sich mit dem Analyzer an einem beliebigen Punkt ins Segment. Je länger die Messung dauert, umso mehr wird klar, wessen Ethernet-Frames »sauber« über die Leitung gehen – oder eben nicht. Nach und nach sind die Stationen zu erkennen, deren Frames regelmäßig – und außerhalb von Kollisionen – defekt sind. Es sind sodann folgende Fälle zu unterscheiden: •

Koax: Angenommen, der Analyzer hängt in der Mitte des Koax-Kabels. Dann »sieht« er beispielsweise »links« nur »gesunde« Frames, dagegen »rechts« sowohl »gesunde« wie »defekte« Frames. Mittels eines Segmentplanes (typischerweise z.B. erstellt in Programmen wie VISIO) ist schnell klar, dass die Frames der zunächst liegenden Stationen »sauber« durchkommen, die der ferner liegenden Adapter dagegen nicht. Die Grenze zwischen »sauber« und »defekt« ist eindeutig bestimmbar, das Problem ist gelöst.

•

Twisted Pair: Betrifft das Problem nur eine Station, war schon die Messung unnötig, da sich ja nur ein einzelner Anwender beklagt hat und die Eingrenzung dadurch schon gegeben war. Betrifft das Problem mehrere Stationen, ist die Frage: Ist ein ganzes Kabelbündel defekt, das vom Verteiler abgeht? Ist der Verteiler (»hub«) selber defekt? Ist das Kaskadierungskabel vom Verteiler zum nächst höheren Verteiler defekt? Die Unterscheidungen sind meistens einfach: Betrifft der Fehler alle Stationen, ist vermutlich der Verteiler oder sein Kaskadierungskabel (UpLink-Kabel) defekt. Der Fehler wird sodann endgültig durch einen Kabel- oder Verteilertausch behoben. Betrifft der Fehler sporadisch wechselnde Stationen, ist dies als Hinweis darauf zu sehen, dass es ein Kabelbündel gibt, innerhalb dessen es zum Übersprechen der Signale kommt. Dies ist insbesondere bei UTP (Unshielded Twisted Pair) zu vermuten.

•

Fiber Optics: Hier stellt sich das Problem kaum, da LWL immer seltener zwischen Repeatern (also innert shared media segments) verwendet werden. Falls doch: siehe oben.

Kapitel 12 • Ethernet

257

Der Analyzer »sieht« alle Frames des Shared Media Segments und er ist in seiner Darstellung einem Kabeltester – dessen Display viel zu klein ist – weit überlegen. Als äußerst günstig erweist es sich, wenn das Analysewerkzeug erlaubt, den einzelnen Stationen eine Farbe zuzuweisen. So kann mittels der Farbe in je einer eigenen Farbtabelle ausgewiesen werden: das Betriebssystem (MS, Apple, NetWare, Unix etc.); die Abteilung; LAN-Segment; Koax-Abschnitt etc. Mit einem solchen Werkzeug sind physikalische Fehler praktisch binnen Sekunden dem einzelnen Adapter bzw. dem einzelnen Kabelsegment zugeordnet. Leider sind solche Möglichkeiten bei nur wenigen Werkzeugen gegeben. Ansonsten sei auf das Kapitel »Physikal Layer« verwiesen, das die genauen Vorgehensweisen darlegt, die bei Fehlern im Physical Layer anzuwenden sind. Es sei auch ausdrücklich auf die dort aufgeführten Hinweise zu den Netzwerkschichten 3 (Network) und 4 (Transport) verwiesen.

12.6

Ethernet Frame-Typen In der Datenkommunikation gemäß dem OSI-Modell verweist jedes niedrigere (im Frame vorne liegende) Protokoll auf das nächst höhere (im Frame unmittelbar dahinter liegende) Protokoll bzw. dessen PCI (Protocol Control Information, auch Protocol Header genannt). Diese grundsätzlich immer vorhandene Verweistechnik gibt es auf dem MACLayer von Ethernet in verschiedenen Varianten. Die Funktion dieses Protokollverweises wird bei Ethernet Data-Link Control genannt. Die verschiedenen Varianten heißen bei Ethernet »Frame Types«, da zwar bei allen Varianten der Ethernet-Frame äußerlich gleich aufgebaut ist, aber unterschiedlich interpretiert wird.

12.6.1 Die verschiedenen Frame-Typen Bei Ethernet hat sich historisch eine Vielzahl von Möglichkeiten entwickelt, wie dieser Verweis (Data Link Control, DLC) erfolgen kann. •

Ethernet II mit EtherType-Feld im MAC-Header (Blue Book Standard/DIX Standard: Digital, Intel, Xerox). Beispiele: – 0x0800 = EtherType für IP – 0x8137 = EtherType für IPX

•

Raw Ethernet mit IPX hinter dem Längenfeld im MAC-Header, ohne LLC dazwischen (NetWare 286 bis 1989) (nur IPX).

258

Ethernet Frame-Typen

•

Ethernet nach IEEE 802.3 mit LLC nach IEEE 802.2 und SAP-Kennungen (z.B. NetBIOS, IPX, AppleTalk) (SAP = Service Access Point). Beispiele: – 0xE0 = SAP für IPX – 0x42 = SAP für BPDU/Spanning Tree – 0xF0 = SAP für NetBIOS

•

Ethernet nach IEEE 802.3 mit LLC+SNAP nach IEEE 802.2 mit EtherType-Feld im SNAP-Header (z.B. IP, AppleTalk). Beispiele: Wie oben unter »Ethernet II«: Es werden dieselben EtherType-Kennungen verwendet; gelegentlich werden sie zur besseren Unterscheidung SnapType genannt, da die Kennung hier nicht im MAC-Header liegt, sondern im nachfolgenden SNAP-Header.

Bei allen Varianten ist der Aufbau des Ethernet-Frames äußerlich identisch; allein das sog. Typ/Längen-Feld wird durch die Treiber unterschiedlich genutzt bzw. interpretiert. Ethernet II Bei Ethernet II (auch: Ethernet Version 2, DIX Ethernet) werden die zwei Bytes nach der MAC Source Address als Kennung für das nachfolgende Protokoll genutzt; diese Kennung wird »EtherType« genannt.

Abb. 12.6: Ethernet II nach DIX Standard

Kapitel 12 • Ethernet

259

Da das Ethernet (in seiner ersten Version, also Ethernet I) von Xerox entwickelt wurde (im PARC, dem Palo Alto Research Center; »Ethernet« ist immer noch eine Registered Trademark der Xerox Corp.), wurden die als EtherType verwendeten Protokollkennungen zunächst ausschließlich von Xerox lizenziert; heute obliegt dies dem IEEE. Die Übergabe der EtherType-Verwaltung ans IEEE ergab sich, als die von Xerox gemeinsam mit Digital Equipment (DEC) und Intel entwickelte Variante Ethernet II beim IEEE als »802.3 CSMA/CD« zum Industriestandard erhoben wurde.

Abb. 12.7: Der »klassische« Fall: Ethernet II mit IP-TCP

Die Abbildung 12.7 zeigt die Sichtweise auf Ethernet zu der Zeit, als an der University of California in Berkely auf Unix TCP/IP entwickelt wurden: Das gesamte Netzwerksystem wurde vorrangig in vier Bereiche (Schichten) eingeteilt, wobei die Kompatibilität zum OSI-Modell durchaus gegeben ist, wenn man den unteren Bereich »Network Access« sowie den oberen Bereich »Process« nur als Platzhalter oder Variablen ansieht, die durchaus Raum für detaillierte Abstufungen lassen – eben so, wie es das OSI-Modell vorsieht. Als durchaus kurios darf angesehen werden, dass die ganze Normungsarbeit des IEEE im Falle von Ethernet+IP heute weitgehend wirkungslos geblieben ist, da viele, wenn nicht sogar die überwiegend meisten LANs nach dieser älteren Variante Ethernet II arbeiten und nicht mit den nachfolgenden IEEE-Varianten. IEEE 802.3 CSMA/CD mit 802.2 LLC Um Kompatibilität zwischen Token-Ring einerseits (IBM) und den bei Ethernet üblich gewordenen höheren Protokollen (IP; IPX, IDP/XNS) zu schaffen, wurde zwischen diese Protokolle der Netzwerkschicht (Network Layer) einerseits und den Ethernet-Header andererseits (MAC Layer) das neue Protokoll LLC (Logical Link Control) gelegt, das seinerseits vom SDLC (Synchronuous Data Link Control, IBM) entlehnt wurde.

260

Ethernet Frame-Typen

Das Problem bestand damals darin, dass Token-Ring-Adapter nur ein einziges Protokoll über sich erkennen können; wechselnde Protokolle waren bis dahin nur bei Ethernet möglich. Der Umbau von SDLC zu LLC ermöglichte dann beides: In Token-Ring-LANs arbeitet immer LLC oberhalb von Token-Ring, aber LLC kann nun seinerseits wechselnde höhere Protokolle tragen. Da LLC dann auch bei Ethernet als »one-and-only« eingeführt wurde (es sollte ebenso wie bei Token-Ring immer gegeben sein), wurde das vormalige Typfeld überflüssig. Da ein Eingriff in die Ethernet-Hardware jedoch abgelehnt wurde, fand dieses Feld weiterhin Verwendung, nur eben eine abgeänderte Verwendung, nämlich zur Angabe eines Längenwertes, der die Menge der nachfolgenden Bytes im Ethernet-Paket anzeigt. Nach diesem Ethernet-Längen-Feld folgt sodann gemäß IEEE immer und ausnahmslos LLC, das seinerseits den Verweis auf das nächsthöhere Protokoll enthält, gekennzeichnet mittels eines sog. SAPs (Service Access Point). Um nun einem empfangenden Ethernet-Treiber die Möglichkeit zu geben, zu erkennen, in welcher Weise die 2-Byte-Kennung nach der MAC Source Address interpretiert werden soll (als Type oder Length), wurden alle bereits bestehenden EtherType-Kennungen von Xerox annulliert, welche einen Dezimalwert hatten zwischen 0 und 1500 – denn dieser Zahlenraum kennzeichnete nunmehr die Länge des nachfolgenden Datenteils. Da das Datenfeld bei Ethernet höchstens 1.500 Byte an Nutzdaten aufnehmen kann, reichen alle Längenkennungen maximal bis zum Wert 1.500 (dezimal); erst höhere Werte ab 1.530 (0x0600) werden wieder (bzw. immer noch) als EtherType-Kennung bewertet. Die älteren, vormalig kleiner/gleich 1.500 verwendeten EtherType-Kennungen wurden durch neue ersetzt, die größer 1.530 sind.

Abb. 12.8: Die wechselhafte Verwendung der zwei Bytes im Typ-Längen-Feld

Die alten EtherType-IDs zwischen 0 und 1.500 wurden – wie gesagt – ersetzt durch neue Kennungen oberhalb 0x0600. Der erste wieder verwendbare TypeWert 0x0600 ist symbolisch mit einem Xerox-Protokoll belegt.

Kapitel 12 • Ethernet

261

Interessant ist, dass einige dieser alten Kennungen, soweit sie nur 1 Byte belegten (bzw. im ersten der zwei EtherType-Bytes »00« enthielten), als LLC-SAP übernommen wurden, so die Kennungen für NetWare (0xE0) und NetBIOS (0xF0).

Abb. 12.9: Ethernet nach IEEE 802.3 mit 802.2 LLC

Raw Ethernet/Novell 802.3 Bevor jedoch der Standard von LLC verbindlich verabschiedet wurde (1985), brachte Novell schon 1983 eine neue Version des Server-Betriebssystems NetWare heraus, in welcher die Übernahme der aktuellen Industriestandards deutlich werden sollte. So widmete Novell das alte Typfeld zum Längenfeld um. Mangels eines fertigen LLC-Standards jedoch wurde wie bei Ethernet-II weiterhin dergestalt gearbeitet, dass hinter dem MAC-Header unmittelbar IPX folgte, obwohl nunmehr mit Längenkennung statt mit EtherType-Kennung gearbeitet wurde. In gewisser Weise war dies ein reiner Marketing-Gag, der technisch nichts brachte – außer vielleicht ein Stück weiterer Verwirrung angesichts der heute insgesamt vier (!) Ethernet Frame-Typen und angesichts der Tatsache, dass diese Novell-Variante den Ethernet-Treiber ein paar Prozessortakte mehr kostet, um überhaupt erkannt zu werden anhand der im IPX-Protokoll vorne stehenden NonPrüfsumme 0xFFFF (heißt: »Checksum Not Used«) – denn nur der sonst unerlaubte Blick über die Grenze von Schicht 2 zu Schicht 3 erlaubt einem EthernetTreiber zu erkennen, dass überhaupt diese spezielle Form der Typ-Längen-Variante vorliegt; und das aber auch nur, wenn bei IPX die Prüfsumme nicht verwendet und somit auf 0xFFFF gesetzt wird. Denn da das normalerweise nach einer

262

Ethernet Frame-Typen

Längenangabe folgende LLC alle möglichen Werte, niemals aber die SAPS 0xFF/ 0xFF (also optisch »FFFF«) annehmen kann, war diese wagemutige Variante so gerade eben möglich. Diese Novell-Creation wird auch »Raw Ethernet« genannt, weil das Ethernet ohne LLC sozusagen noch »roh« ist, nicht gekocht und nicht verarbeitet.

Abb. 12.10: Die Novell-Creation »Novell 802.3« – zwar mit Länge, aber ohne LLC

IEEE 802.3 CSMA/CD mit LLC-SNAP Das IEEE war bei seiner Planung offenbar davon ausgegangen, dass das Ende der Zeit gekommen wäre – zumindest das Ende aller Protokollentwicklung. Nur so ist zu erklären, dass das EtherType-Feld mit seiner Länge von immer 2 Byte ersetzt wurde durch den SAP (Service Access Point) genannten Verweis auf das hinter LLC folgende Protokoll mit nur noch 1 Byte Länge, wovon kurioserweise noch nicht einmal alle 8 Bit zur Verfügung stehen, weil ganze 2 Bit speziellen Codierungen dienen. Somit schrumpfte die Zahl der kennzeichnungsfähigen Protokolle von 65.535 auf sage-und-schreibe magere 64. Die waren denn auch flugs vergeben. Parallel zu der Standardisierung von Ethernet, Token-Ring und LLC beim IEEE (1982-1985) verlief die Entwicklung der TCP/IP-Protokolle im Auftrage des USMilitärs an der University of California in Berkeley (1981-1983). Da den LAN-Stationen mit ihren im Adapter eingebrannten Hardware-Adressen (= MAC-Adressen) jeweils eine im IP-Treiber hinterlegte logische Adresse beige-

Kapitel 12 • Ethernet

263

ordnet wurde (=IP-Adresse), wurde für die LAN-Kommunikation via IP und Ethernet erforderlich, dass jeder IP-Absender nicht nur die IP-Adresse seines Gegenübers kennt, sondern auch die Ethernet-MAC-Adresse. Dies wurde zunächst auf den Unix-Rechnern, auf denen die TCP/IP-Protokolle entwickelt wurden, erreicht durch die Datei /etc/ethers – einer Tabelle, in der sich IP- und MAC-Adresse aller Teilnehmer gegenüberstehen. Mit der zunehmenden Akzeptanz von TCP/IP sowie dem nachfolgenden Anstieg der IP-Teilnehmer in den explosionsartig wachsenden LANs wurde es praktisch unmöglich, die /etc/ethers aktuell zu halten. Weder konnte man allen Mitarbeitern eines Hauses auferlegen, diese Tabelle selber zu pflegen (wie auch?), noch war Datei-Distribution die Lösung (zumal mit ftp!), da die Tabellen praktisch täglich Änderungen unterlegen waren. Dadurch wurde ein Wechsel im Vorgehen erzwungen. Als Folge dessen wurde das ARP entwickelt als Address Resolution Protocol = Adress-Auflösungs-Protokoll. Fehlt einem IP-Treiber die MAC-Adresse des Empfängers, so veranlasst er via ARP einen LAN-Broadcast: »Hallo, an alle! Wem gehört die IP-Adresse 47.11.08.15 ??« Diesen Rundruf hören alle aktiven Ethernet-Adapter mit und reichen ihn an den über ihnen liegenden ARP-Treiber weiter. Erkennt ein ARP-Treiber seine eigene IP-Adresse, antwortet er und teilt dem Fragenden die gewünschte MAC-Adresse mit. Dieser nimmt die neue MAC-Adresse in seine ARP-Tabelle auf und kann daraufhin die eigentliche Übertragung starten. Dieses Verfahren jedoch stürzte alle Anwender in der Mitte der 80er Jahre in ein böses Dilemma: Entweder arbeiteten sie IEEE-konform mit LLC, dann aber ohne ARP (da kein SAP mehr frei war für ARP), oder sie verwendeten grundsätzlich wieder Ethernet-II. Das war zwar für Ethernet-Anwender eine erträgliche Lösung, nicht aber für IBM und seine Token-Ring-Anwender, da der Token-Ring-Header kein Typfeld kennt und auch ansonsten immer LLC verwendet werden musste. Somit musste eine Erweiterung zu LLC definiert werden: SNAP = SubNetwork Access Protocol. Und – siehe, da! – schon taucht ein alter Bekannter wieder auf: Das gute, alte EtherType-Feld als Teil von LLC-SNAP. Die Industrievertreter beim IEEE jedoch hatten aus ihrem Fehler gelernt und befürchteten nun, dass auch der 2-Byte-Adressraum mit seinen 65.535 Möglichkeiten eines Tages zu eng sein könnte, und stellten dem SNAP-Type-Feld ein 3 Byte langes Feld vor, das typischerweise den Herstellercode enthalten kann, den es schon in den ersten 3 Byte einer jeden MAC-Adresse gibt (Ethernet, TokenRing, FDDI), oder sonstige Kennungen, um Protokollfamilien von einander abzugrenzen.

264

Ethernet Frame-Typen

War ursprünglich vorgesehen, IP over LLC zu senden mit der IP-Kennung SAP=0x06, so wurde diese Variante nunmehr für ungültig erklärt zugunsten der Variante IP over SNAP unter der Verwendung derselben IP-Kennung, die schon Ethernet-II verwendet hatte: IP = 0x0800. Neu hinzu kam jetzt ARP = 0x0806.

Abb. 12.11: Ethernet mit LLC-SNAP

Somit kann IP entweder über Ethernet-II oder über Ethernet-SNAP gesendet werden. Dies kann noch als einigermaßen übersichtlich bezeichnet werden, da es »nur« zwei Möglichkeiten für IP sind. Kurioser ist es bei IPX, das in allen vier Varianten gesendet werden kann – nach wie vor. Zuletzt muss bei LLC-SNAP erneut darauf hingewiesen werden, dass es sich eigentlich nur um eine für Token-Ring gedachte Variante handelt. Wer über Token-Ring gerne einmal lästert, könnte mit Fug und Recht behaupten, dass LLCSNAP die erste Form von LAN-Emulation war (und immer noch ist), emuliert doch der SNAP-Header einem IP-Treiber gegenüber die alte Ethernet-Schnittstelle, obwohl im Physical Layer mit Token-Ring gearbeitet wird. So ist es de facto gegeben, dass jeglicher IP-Treiber bis heute fest daran glaubt, über Ethernet zu arbeiten – denn wo ein IP-Treiber ist, da ist auch ein EtherTypeFeld.

Kapitel 12 • Ethernet

265

12.6.2 Fehler beim Frame-Typ und ihre Erkennung Diese bis zu vier verschiedenen Interpretationen des Ethernet-Headers bringen Probleme, wenn verschiedene Rechner im Netzwerk unterschiedliche FrameTypen verwenden. So ist ein Rechner, der nur Ethernet-II versteht, inkompatibel zu einem anderen, der nur Ethernet-SNAP versteht – und so weiter, und so weiter. Fehlervermeidung Die einfachste Möglichkeit, jede Form von Missverständnis auszuschließen, ist, bei den Servern alle vier Varianten des Ethernet-Treibers einzurichten. So kann definitiv jeder Client mit allen Servern kommunizieren. Ansonsten sollte nur ein einziger Frame-Typ verwendet werden – oder doch so wenige wie eben möglich. Häufige Fehler Zu den »fiesen« Fehlern gehören genau die, die als solche nicht sofort sichtbar werden. So hier bei den Ethernet Frame-Typen: Werden bei Novell NetWare die File Server mit verschiedenen Frame-Typen betrieben (es sind eben nicht alle Frame-Typen geladen, und dann noch hier und da verschiedene Frame-Typen), und ist dies bei den Client-PCs ebenso, so kann Folgendes geschehen: Versucht Client_1, der sonst nur mit Server_1 via Ethernet-II spricht, ausnahmsweise mit Server_2 zu sprechen, der nur Ethernet-LLC versteht, so erhält er von Server_2 beim Versuch des Verbindungsaufbaus keinerlei Antwort (wie auch?); der Anwender bemerkt zunächst jedoch nichts, weil nämlich Server_1 in die Bresche springt, weil er – zufälligerweise – ebenfalls neben Ethernet-II auch Ethernet-LLC versteht. Er bietet nun seine Dienste an und übernimmt ein EtherTypeRouting: Er nimmt alle Requests von Client_1 im Format Ethernet-II an, tauscht den Header aus gegen Ethernet-LLC und schickt den Request weiter an Server_2; der antwortet mit Ethernet-LLC und schickt seinen Reply an Server_1, der seinerseits erneut den Header austauscht und den Reply von Server_2 an Client_1 zurück schickt via Ethernet-II. Dieses Beispiel funktioniert natürlich auch in allen anderen denkbaren Variationen. Das Hässliche daran ist, dass der Anwender zunächst nichts bemerkt, denn die Verbindung kommt ja zustande. Er – und mit ihm alle anderen Anwender – wundert sich aber darüber, dass »das Netz so langsam wird«. Denn Server_1 hat nunmehr doppelte Arbeit zu verrichten, und alle Pakete an Server_2 sind doppelt auf der Leitung. So steigert man den Bruttodurchsatz mal eben um 100% (wenn’s alle Anwender betrifft) bzw. senkt den anteiligen Nettodurchsatz um 50%.

266

Bridges/Switches, Spanning Tree & BPDU

Und schon wieder wird darüber nachgedacht, 100-Mbps-Ethernet (Fast Ethernet) oder Gigabit- oder Terabit-Ethernet einzusetzen... oder die Lösung liegt darin, auf NetWare 5 umzusteigen und nur noch IP zu verwenden... so haben kleine Fehler oft ungeahnte Folgen. Der Hinweis, dass IPX (NetWare) jetzt immer mehr abgelöst wird von IP (NetWare/ WinNT), sticht schon deswegen nicht, weil nun eben IP-Routing-Fehler ähnliche Effekte auslösen (wie der Autor mit großem Vergnügen des Öfteren live erleben darf). Man muss sein Netzwerk nur lange genug ohne Dokumentation betreiben, dann stellen sich solche »netten« Fehler über kurz oder lang von selber ein.

12.7

Bridges/Switches, Spanning Tree & BPDU

12.7.1 Das Konzept der Transparent Bridges Ethernet-Domains (Time Domains/Collision Domains) werden physikalisch getrennt bzw. logisch verbunden über Bridges bzw. Switches (die nach IEEE 802.1d als »Switching Bridges« gelten). Da bei Ethernet die Adapter von vorhandenen Brücken nichts wissen (im Gegensatz zu Token-Ring-Adaptern), heißen sie »Transparent Bridges« (im Gegensatz zu den »Source Routing Bridges« bei Token-Ring). Diese Bridges können untereinander verschaltet/verbunden werden, um für den Fall eines Bridge-Breakdowns oder eines Kabelfehlers ausreichend Ersatzwege zur Verfügung zu stellen (Redundanz). Diese Ersatzwege dürfen aber bei Normalbetrieb nicht für den Datenverkehr zur Verfügung stehen, da sich sonst EthernetSchleifen (loops) bilden würden mit der Folge, dass Datenpakete endlos in einem Ethernet-Ring kreisen könnten, ohne je entfernt zu werden. Token-Ring löst dieses Problem daduch, dass jeder Absender seinen eigenen Frame wieder vom Ring nimmt bzw. ersatzweise der sog. Active Monitor (ein hierfür dynamisch eingeteilter Token-Ring-Adapter). Dies ist bei Ethernet nicht möglich – einerseits ist die erforderliche Logik nicht implementiert, andererseits ist die Technik der passiven Signalabnahme bei Ethernet ein unüberwindliches physikalisches Hindernis. Um nun den drohenden Loop nicht eintreten zu lassen, müssen sich die EthernetBridges untereinander verständigen und die überzähligen Leitungen stilllegen; nur im Falle eines Ausfalles dürfen (sollen) sie aktiviert werden. Der jeweilige Bridge-Port, der nicht aktiv verwendet werden darf, wechselt in den »Stand-by«Modus. Hierdurch wird bei Ethernet der Zwang erzeugt, alle Daten auf einen zentralen Punkt hin zu konzentrieren (weswegen die »Multi-Port-Repeater« zunächst »Concentrator« genannt wurden, bevor sie sehr missverständlich in »Hubs« umgetauft wurden).

Kapitel 12 • Ethernet

267

Die gleichzeitige Verwendung paralleler Wege – wie dies Token-Ring kennt – ist nicht möglich. Somit ist der Zwang gegeben, zu Fast Ethernet oder Gigabit Ethernet zu wechseln (und womöglich irgendwann noch zu Terabit-Ethernet). Somit ist aber auch immer ein Single Point of Failure gegeben. Dem begegnen seit einiger Zeit zusätzliche Entwicklungen, deren erste von Cisco stammte (ISL und HSRP), die nach und nach diesen Mangel im Redundanz-Konzept von Ethernet abstellen (sollen). Doch zurück zum Spanning-Tree-Standard: Die Ethernet-Bridges verständigen sich mit einem eigenen Protokoll, um zu ermitteln, welche aktuelle Topologie gegeben ist (das heißt, welche Kabel und Bridges aktiv sind). Dieses Protokoll wird schlicht »BPDU« genannt (Bridge Protocol Data Unit). Der Algorithmus, der die BPDU-Nachrichten verarbeitet und in jeder Bridge ein Bild der aktuellen Topologie gibt, ist der sog. »Spanning Tree Algorithm«. Der Ausfall einer Bridge bzw. eines Leitungsweges wird erkannt anhand des Ausbleibens der BPDUs einer Nachbar-Bridge.

12.7.2 Fehler: zu lange Umschaltzeiten Fehler mit Bridges sind bei Ethernet überaus selten. Manchmal ereignen sich Fehler, die darin bestehen, dass diese Ethernet-Entwicklung auf Token-Ring-Bridges portiert wird und es dort dann zu Fehlern kommt, weil die Implementation unsauber war. (Dies hat der Autor schon erlebt und messtechnisch belegt.) Ein bestimmter Konfigurationsfehler kann schon häufiger negative Auswirkungen haben: Gemeint ist die zu lange Umschaltzeit der Ethernet-Bridges im Falle, dass ein Ersatzweg aufgeschaltet werden muss. Häufig werden Bridges/Switches mit den werksseitig vorgegebenen Defaults in Dienst genommen – und somit ggf. mit zu langen Umschaltzeiten. Kurze Umschaltzeiten sind aber unabdingbar notwendig, um bei einem Ausfall mit nachfolgender Umschaltung die aktuellen Client-Server-Sessions nicht unnötig sterben zu lassen. So verkraftet beispielsweise ein IPX-Treiber eine Unterbrechung von 19 Sekunden; ab einer Trennung von 20 Sekunden schon kann die Session sterben. Somit sollte bei Standardmessungen im Ethernet nebenher geprüft werden, ob die Bridges/Switches richtig eingestellt sind. Diese Überprüfung ist ohne weiteres möglich, da mit jeder BPDU, die alle paar Sekunden gesendet wird, alle Konfigurationsdaten bekannt gegeben werden.

268

Ethernet Multicast Addresses

12.7.3 Fehler: falsche (= zu langsame) Ersatzwege Der Ersatzweg, der im Falle eines Ausfalles aktiviert wird, ist von vornherein durch die Topology Map vorgegeben, die durch den Spanning Tree Algorithm in jeder Bridge aufgebaut wird. Was nutzt ein Ersatzweg beispielsweise für eine ausgefallene Fast-EthernetStrecke, wenn die Ersatzstrecke nur mit 10 Mbps läuft? Hier ist die Einstellung der sog. Bridge Priority entscheidend: Über Prioritätswerte ist vorherbestimmt, welche Bridge bzw. welcher Port im Falle des Ausfalls aktiv wird. Auch dies ist also bei gelegentlicher LAN-Analyse zu prüfen.

12.7.4 Filter auf BPDU Es genügt, einen Filter zu setzen auf die Multicast-Adresse der Spanning-TreeBridges: 0180C2.000000 = Spanning Tree BPDU MAC Multicast Address.

Oder es wird ein Filter auf die LLC-SAP-Kennungen für BPDU eingerichtet: 0x42 = LLC-SAP für BPDU.

Womit wir beim letzten Abschnitt angelangt wären.

12.8

Ethernet Multicast Addresses Einige Protokollfamilien verwenden geschützte bzw. reservierte Multicast-Adressen. Was sind Multicasts? Es sind entweder Gruppen- oder Funktionsadressen, deren Verwendung als MAC Destination Address dazu führt, dass entweder eine Gruppe von Ethernet-Adaptern sich angesprochen fühlt, oder dass bestimmte Funktionen in beliebigen Rechnern angesprochen werden. Eine Funktionsadresse beispielsweise ist die der Spanning-Tree-Bridges mit 0x0180C2.000000 – denn die ersten drei Byte bezeichnen nicht wie sonst üblich einen Hersteller, sondern eine Funktion. Solcherlei logische Funktionskennungen wurden bei der MAC-Adressierung (und eben auch bei Multicasts) hauptsächlich bei DECnet verwendet. Das aber ist heute schon zur Rarität mit Museumswert geworden. Die Verwendung von IPX und IP in fast allen Architekturen hat die geschützten Multicast-Adressen nahezu überflüssig gemacht.

Kapitel 12 • Ethernet

269

Genannt werden dieselben hier, weil sie beim ersten Schritt der Analyse eine Rolle spielen, wenn es darum geht, einen Überblick zu gewinnen bezüglich der im Netz aktiven Komponenten. Eine bekannte und häufig genutzte MAC-Multicast-Adresse ist 0x030000.000001 für NetBIOS-Teilnehmer (bei Microsoft ist dies die Treiber-Variante NetBEUI). Filter auf (Protokoll-Feld/Parameter) ...

Offset

Wert (hex)

Multicast Address für BPDU

00

0180C2.000000

Multicast Address für NetBIOS

00

030000.000001

Tab. 12.3: Filter auf gängige Multicast-Adressen bei Ethernet

Weitere Multicast-Adressen sind auf der beiliegenden CD-ROM oder im Internet zu finden unter: http://www.synapse.de/ban/

Kapitel 13 Token-Ring 13.1 13.2 13.3 13.4 13.5 13.6 13.7 13.8 13.9 13.10 13.11 13.12 13.13 13.14

Einführung Das Werkzeug Der Token-Ring Header Das MAC-Protokoll: Funktionen und Filter Vorgehensweise in der Analyse Filter auf das MAC-Protokoll Die logischen Adressen von Token-Ring Token Ring Source-Routing Token Ring Access Priority Ferndiagnose via RMON und CMOL Token-Ring, LLC-SNAP und Ethernet Transparent vs. Source-Route Bridging TokenSwitching Ausblick: Der Ring lebt (noch)

272 274 275 278 300 302 306 309 316 319 320 321 321 322

272

13.1

Einführung

Einführung Und der Ring sprach: »Ich bin der Herr, dein Ring, du sollst keine anderen SNA-FEPs haben neben mir, und du sollst mich auch nicht gerade biegen.« Und das Ethernet antwortete: »Emulier’ du ruhig deinen FEP, den sowieso keiner mehr braucht – aber LAN, das bin ich.« Bevor wir uns der Analyse von Token-Ring zuwenden, müssen wir uns über das Grundprinzip dieser Technik klar werden, und das Grundprinzip lautet: Der Token-Ring ist ein über die Fläche verteilter FEP (Front End Processor), und der ist ein Stück vom SNA-Host, und an dem hängen dumme SNA-Terminals. Das klingt unwahrscheinlich? Betrachten wir die Geschichte: In den 60er und 70er Jahren erlebte IBM großen Erfolg mit seiner Rechnertechnik. Der Erfolg war so groß, dass nicht nur immer mehr Kunden einen IBM-Mainframe haben wollten, sondern dass auch bei jedem einzelnen Kunden immer mehr Anwender am Host arbeiten sollten. Es mussten also immer mehr Terminals (Datensichtgeräte, Eingabe-/Ausgabegeräte) am Host angeschlossen werden. Als die Kabelbäume daraufhin immer dicker wurden und in den Steigschächten keinen Platz mehr fanden; und als sämtliche Möglichkeiten, am Host noch ein Terminal-Interface einzubauen, ausgeschöpft waren, wurde der FEP (Front End Processor; Steuereinheit) als Schnittstellen-Multiplexer (MUX) erfunden. Der IBM-Mainframe brauchte nur noch einige wenige Anschlüsse zu den FEPs, die ihrerseits nunmehr die Terminal-Interfaces aufnahmen. So konnte man die Terminal-Anschlusskabel (Koax) auf mehrere FEPs verteilen, und für ein paar Jahre waren wieder Wachstum und Migration gesichert. Doch auch diese Architektur – inzwischen SNA genannt (Systems Network Architecture) – kam wegen der rasant zunehmenden Bedürfnisse der Kunden nach immer mehr Terminals je Host an ihre Grenzen. Was tun? Auf diese drängende Frage fanden die IBM-Techniker folgende Lösung: Anstatt mit immer dickeren Kabelbäumen immer mehr Schächte zu füllen, indem das Terminal mit einem eigenen Kabel seinen Weg zum FEP-Interface finden musste, sollten nunmehr die FEP-Interfaces zum Terminal kommen und somit über die Fläche verteilt werden. Diese FEP-Interfaces (= Terminal-Anschlüsse) sollten sodann untereinander durch nur noch ein einziges Kabel verbunden werden: Die Idee des Ringes war geboren. Anfänglich galt das Entwicklungsziel tatsächlich nur dem Wunsch, die bekannten Terminaltypen auf diese Weise im Ring zusammenzuschalten. Dies war Mitte der 70er Jahre. Das Token-Ring MAC-Protokoll spiegelt diese Entwicklung immer

Kapitel 13 • Token-Ring

273

noch exakt wieder: Jeder Ring emuliert heute immer noch einen FEP. Genauer: Der Ring ist der FEP. Während ein echter FEP seine Terminals der Reihe nach abfragt (Polling), ob sie denn einen Tastatur-Anschlag für ihn hätten, den er in Monitorzeichen umzurechnen hätte, fragt heute das Token (= Pfand, Senderecht) jeden einzelnen Adapter, ob er eine Übertragung durchzuführen wünscht. Das Token wird von einem bestimmten Adapter erzeugt und überwacht, dem sog. Active Monitor. Ansonsten werden die Token-Ring-Adapter von einer Ring-Management-Station überwacht und angeleitet, dem Ring Parameter Server (RPS) bzw. Configuration Report Server (CRS). Der RPS/CRS hat absolute Macht über jeden Adapter; er spricht jedem neuen Adapter gegenüber seine Duldung aus – oder auch nicht, denn der RPS/CRS kann jederzeit einen Adapter aus dem Ring werfen, wenn dieses geboten erscheint (Sicherheitsgründe). Jeder Token-Ring-Adapter ist also einem strengen Überwachungsreglement unterworfen und unterscheidet sich insofern kaum von seinem Vorgänger, dem »waschechten« SNA-Terminal, das ebenfalls vollständig abhängig war – vom FEP. IBM bildete zudem im Token-Ring-Adapter die PU-Nummern von SNA ab (PU=Physical Unit), und noch heute hat ein RPS/CRS durchaus die Angewohnheit, »seine« Token-Ring-Adapter zu fragen: »Was ist denn heute bei dir angeschlossen?« (Request Ring Station Attachment) Es könnte ja statt des PCs auch ein alter SNA-Drucker oder doch ein altes SNA-Terminal sein. Dass dies seit mehr als einem Jahrzehnt nicht mehr der Fall und u.a. durch 3270-Emulationen überholt ist, merkt der RPS/CRS gar nicht. Für ihn ist die Zeit Ende der 70er Jahre stehengeblieben. Diese Konzeption wurde dann Anfang der 80er Jahre durch zwei Entwicklungen überholt, die in den 70er Jahren niemand voraus gesehen hatte. Erstens: Die Generation der Microcomputer wurde geboren. Was Hersteller wie Sinclair und Apple vormachten, ließ auch IBM nicht unberührt, und Anfang der 80er Jahre entstand der IBM-PC (Personal Computer) mit dem Betriebssystem MS-DOS (Microsoft Disk Operating System). Der PC löste nunmehr als Endgerät das alte Terminal ab. Zweitens: Die stürmische Entwicklung der damals schon lange ausgereiften Ethernet-Technik in den 70er Jahren sowie die darauf bauende Entwicklung von TCP/IP in den frühen 80er Jahren setzte IBM unter weiteren, großen Zugzwang, sich anzupassen. Beide Bewegungen führten dazu, dass der IBM Token-Ring schließlich nicht mehr genau das war, als was er gedacht war: Er war kein FEP mehr, sondern ein LAN. In dieser Formulierung liegt zwar Überspitzung, aber eben auch Wahrheit. Heute bringt es den Ring manchmal durcheinander, wenn alte SNA-Technik sowie die von Ethernet herkommende Client-Server-Technik zusammen kommen, und dann treten Probleme der schwersten Art auf. Dies ist insbesondere dann der Fall, wenn mit dem sog. Token-Ring Source-Routing gearbeitet wird.

274

Das Werkzeug

Ethernet, das sich niemals mit einer komplexeren Logik beschwerte, hat alle diese Probleme nie gekannt. Ethernet ist so »dumm«, dass es die Gelegenheit zu logischen Fehlern von vornherein kaum hat. Der Token-Ring wird heute mit höheren Protokollen betrieben, die ursprünglich niemals für den Ring gedacht waren: IPX (IDP/XNS), IP, AppleTalk usw. Alle diese Protokolle sind echte LAN-Protokolle mit eigenen Routing-Mechanismen, denen gegenüber sich der Token-Ring widerspenstig zeigt. Das am nächsten mit dem Token-Ring verwandte Protokoll, NetBIOS, weist nicht etwa zufällig, sondern gewollt keinerlei Routing-Mechanismen auf – ein Grund, weswegen NetBIOS entweder abgeschafft oder hilfsweise über IPX oder IP betrieben wird. In der Token-Ring-Historie liegen Abgründe verborgen, in denen sich schlimme Betriebsfehler verstecken (können); insbesonderen dann, wenn die heute vorherrschenden LAN-Systeme (NetWare, WinNT, IPX, IP) zusammentreffen mit SNAAnwendungen und Token-Ring Source-Routing. Wir werden sehen, dass einige der typischen Token-Ring-Probleme sich aus diesem Szenario ergeben: Konkurrierende Routing-Anweisungen auf den Schichten 2 und 3 können von großem Übel sein. Was würde ein Ethernet-Adapter einem Token-Ring-Adapter sagen, der Probleme hat? »Das hast du davon, wenn du mit LLC-SNAP LAN-Emulation machen willst. Bleib du nur FEP !! Ich allein bin LAN, du nicht.«

13.2

Das Werkzeug Zu dem bereits in Kapitel 2 Gesagten über Analysatoren muss noch einiges hinzugefügt werden: Bei Token-Ring gibt es nach der langen Erfahrung des Autors nur zwei Werkzeuge, die das Maximum an Leistungen bieten, wenn es dem Ring an den Kragen geht. Produkt zur Token-Ring Analyse

Hersteller

TokenVision

Triticom, USA

LANdecoder/tr

Triticom, USA

Tab. 13.1: Zwei alte, aber immer noch ungeschlagene Token-Ring-Tools

Beide Werkzeuge sind vom selben Hersteller und laufen unter DOS. Dies hat wesentlich damit zu tun, dass die meisten Hersteller sich auf Ethernet-Analyzer spezialisierten (der Ethernet-Markt war und ist deutlich größer). Dass hier DOSWerkzeuge genannt werden, hat zwei Gründe:

Kapitel 13 • Token-Ring

275

Erstens sind beide Programme in der Lage, unmittelbar – ohne Treiber – auf den Chipsatz einer 16-Bit-Karte zuzugreifen, was eine extreme Leistungsstärke garantiert, und zweitens sind sie für Token-Ring in vielen Punkten deutlich besser geeignet als ihre Windows-Nachfolger. Da in den USA Token-Ring praktisch keine Rolle mehr spielt, sind die Windows-Analyzer kaum noch auf Token-Ring hin optimiert. Die Wahl dieser beiden Werkzeuge bedeutet keine Einschränkung, sondern die



             

                

Spielt dieser Gedanke keine so große Rolle, so kann ohne Bedenken auch einer der neuen Windows-Analyzer verwendet werden. Es darf schließlich nicht übersehen werden, dass ein DOS-Analyzer seinerseits gegenüber den Windows-Analyzern schwerwiegende Nachteile hat. Und doch zeigt die Praxis: Bei Kunden seines Unternehmens sieht der Autor immer noch diese beiden Werkzeuge von Triticom unter DOS im Einsatz, obwohl dieselben Kunden auch längst über die Windows-Analyzer verfügen. Schon diese Tatsache spricht für sich.

13.3

Der Token-Ring Header

13.3.1 Aufbau des Token-Ring Headers Zu Beginn sei die Struktur des Token-Ring Headers erläutert:

Abb. 13.1: Der Token-Ring Frame-Aufbau (Header, Trailer/PCI)

276

Der Token-Ring Header

Die folgende Tabelle führt die Protokollfelder einzeln auf und erläutert sie: Länge

Bedeutung

1 Octet

SD = Starting Delimiter Zeigt den Paketbeginn an durch Abweichungen vom binären Differential Manchester Code.

1 Octet

AC =
   Dient der Zugriffssteuerung und enthält das Token; mit Reservierungsund Prioritäts-Bits für bevorzugte Token-Vergabe an bevorrechtigte Adapter.

1 Octet

FC =

   Inhaltsangabe; hier wird mit dem Wert der ersten zwei Bits unterschieden in MAC-Frames (»00«) und LLC-Frames (»01«). Im Falle von MAC-Frames wird der Inhalt weiter aufgeschlüsselt durch den sog. Attention Code.

6 Octets

MAC Destination Address 3 Byte Herstellerkennung 3 Byte Stationskennung des Empfängers

6 Octets

MAC Source Address 3 Byte Herstellercode 3 Byte Stationszähler des Absenders

n Octets

RIF =       Im Falle von Source-Routing enthält das RIF die Wegeangaben (Bridge ID, Port ID, etc.)

1–4096 Octets/Byte

Nutzdaten/Information Protokolle höherer Schichten & Anwendungsdaten, allgemein unterschieden in »MAC Data« und »LLC Data« (siehe

  
   

          

4 Octets

FCS =

   Enthält die CRC-Prüfsumme

1 Octet

ED =   

Mit dem Error Recognized Bit, mit dem ein als fehlerhaft erkannter Frame abgestempelt wird.

1 Octet

FS =

   Mit Address Recognized/Frame Copied Bits (A/C-Bits) als Stempelfelder zur Annahmequittung seitens des Frame-Empfängers.

Tab. 13.2: Protokollfelder des Token-Ring Frames

Das leere Token enthält nur ein einziges Protokollfeld zwischen SD und ED, nämlich Access Control. Die Abbruchkennung, die nach unvorhergesehenem Abbruch einer Übertragung gesendet wird, die Abort Sequence, besteht sogar nur aus SD und ED.

Kapitel 13 • Token-Ring

277

Abb. 13.2: Token, Abort Sequence, PDU bzw. Data Frame

Die vollständige Beschreibung der Token-Ring PCI (Protocol Control Information) ist zu finden unter: http://www.synapse.de/ban/

13.3.2 SDU+PCI=PDU Weiterhin sei an das Strukturprinzip der Protokollanalyse erinnert, wonach jedes Protokoll einer bestimmten Schicht kommuniziert mit dem entsprechenden Treiber des Kommunikationspartners über Steuerdaten, die PCI (Protocol Control Information) genannt werden; gemeinsam mit der Datenmenge, welche die höhere Schicht zwecks Übertragung an die tiefere Schicht übergibt und die SDU (Service Data Unit) genannt wird, bildet die PCI die sog. PDU (Protocol Data Unit). Kurz gesagt: SDU+PCI=PDU.

Abb. 13.3: Das Prinzip von PCI und PDU im OSI-Modell

278

13.4

Das MAC-Protokoll: Funktionen und Filter

Das MAC-Protokoll: Funktionen und Filter Wenn die Token-Ring-Adapter untereinander Meldungen austauschen bzw. einander zusenden, geschieht dies mit dem sog. MAC Protocol von Token-Ring.

13.4.1 SD – Starting Delimiter Der Starting Delimiter hat die Aufgabe, das durchgehend gesendete Frequenzsignal (Idle Symbol) zu unterbrechen – und zwar nicht physikalisch, da der Ring immer mit einem Signal abgedeckt sein soll bzw. muss, sondern logisch, indem für einen kurzen Moment die sonst gültige Regel des physikalischen Codes, des sog. Differential Manchester Code, durchbrochen bzw. verletzt wird, indem zweimal in einem Doppel-Bit auf den zur Bit-Mitte vorgeschriebenen Pegelwechsel verzichtet wird, wodurch jeweils ein Gleichstrompegel erreicht wird, der sonst verboten ist. Diese Doppel-Bits werden als »JK« bezeichnet, was an Flip-FlopSchaltungen in der Elektrotechnik erinnern soll. Diese gezielte Code-Verletzung darf nur in SD und ED auftauchen. Tritt sie an anderen Stellen auf, wird dies erkannt und als Fehler gemeldet. Sind mehr als fünf Halb-Bit-Zeiten (also zwei-einhalb Bits) mit Gleichstrompegeln kodiert, gilt dies als Burst Five Condition und wird ein sog. Burst Error gemeldet. Dies ist regelmäßig bei Relaisschaltungen am Ringleitungsverteiler der Fall, da während der Umschaltzeit des Relais’ das Token-Ring-Signal unterbrochen ist, bis der Kontakt wieder geschlossen ist. Tauchen diese Fehler außerhalb von Relaisschaltungen auf, liegt definitiv ein ernst zu nehmender Fehler vor. Es kann ein Wackelkontakt vorliegen, Kurzschluss, Adapterdefekt – alles, was das modulierte Frequenzsignal zu unterbrechen oder zu zerstören geeignet ist.

Abb. 13.4: Das Feld »Starting Delimiter« (Begrenzungszeichen)

Kapitel 13 • Token-Ring

279

Um Fehler dieser Art zu finden, können Filter auf die Fehlermeldungen gesetzt werden. Siehe hierzu: Abschnitt 13.4.14 »Soft Errors« bzw. 13.4.15 »Isolating/ Non-Isolating Soft Errors«. Während der SD sonst keine weitere Bedeutung hat, enthält der ED (s.u.) noch zwei wichtige Markierungs-Bits (Stempelfelder).

13.4.2 AC – Access Control Das MAC Protocol von Token-Ring hat unmittelbar die Aufgabe, das Token bereitzustellen bzw. abzusichern. Die für jede Art von MAC (Media Access Control) vorrangige Frage lautet: Wer darf wann was senden und empfangen? Das Token stellt das Senderecht dar; es wird von Adapter zu Adapter im Ring reihum gereicht; nur der Adapter, der es gerade hat, darf ein Datenpaket senden.

Abb. 13.5: Das Feld »Access Control« (1. Oktett im Token-Ring Header)

Steht das Token-Bit im Feld Access Control auf »0«, handelt es sich um ein freies Token; der gesamte MAC-Frame besteht dann nur aus Starting Delimiter plus Access Control plus Ending Delimiter. Die Existenz und reguläre Verwendung des Tokens wird vom Active Monitor überwacht, einem hierfür eigens auserkorenen Adapter. Der Active Monitor generiert das Token, wenn es verloren ging, und wacht darüber, dass es nicht endlos besetzt oder belegt im Ring kreist – was geschehen kann, wenn ein Adapter, der das Token zur Übertragung eines Datenpaketes nahm, genau dieses Datenpaket nicht mehr vom Ring nimmt und folglich das Token nicht mehr weitergibt. Wer immer ein Datenpaket sendet, hat es auch wieder vom Ring zu nehmen. Um dem Active Monitor hierüber die Kontrolle zu ermöglichen, wird jeder Frame gesendet mit einem auf »0« gesetzten Monitor Bit (M-Bit).

280

Das MAC-Protokoll: Funktionen und Filter

Der Active Monitor (AM) stempelt jeden vorbeikommenden Frame ab, indem das M-Bit auf »1« gesetzt wird. Sieht der AM ein Paket, welches M=1 enthält, so muss dieses bereits den Ring vollständig umkreist haben; folglich nimmt der AM das Paket vom Ring und gibt ein neues Token aus. Jeder Ausgabe eines neuen Token geht ein MAC-Frame mit dem Befehl Ring Purge voraus, was alle Adapter im Ring anweist, sämtliche Aktivitäten einzustellen und auf das neue Token zu warten. Auf die Verwendung und Wirkung der R-Bits und P-Bits (Revervation/Priority) wird eingegangen im Abschnitt 13.9: »Token-Ring Access Priority«.

13.4.3 FC – Frame Control Der Unterschied zwischen Übertragungen, die Daten des MAC Protocol enthalten, und solchen, die User Data bzw. Daten höherer Protokolle enthalten, wird im zweiten Oktett des Token-Ring Headers gekennzeichnet, und zwar in den ersten zwei Bits des Protokollfeldes Frame Control.

Abb. 13.6: Das Feld »Frame Control« (2. Oktett im MAC-Header)

Um einen Filter auf die Frames des MAC Protocols anzulegen, müssen alle Frames angesprochen werden, die im Feld Access Control in den ersten beiden Bits den Wert »00« haben: Filter auf (Protokoll-Feld/Parameter) ...

Offset

Wert (binär/hex)

Alle Token-Ring LLC Frames

01

01XXXXXX = 0x4X

Alle Token-Ring MAC Frames

01

00XXXXXX = 0x0X

MAC: Normal Frame

01

00000000 = 0x00

MAC: Express Frame

01

00000001 = 0x01

MAC: Beacon – BCN

01

00000010 = 0x02

Tab. 13.3: Filter auf Werte im Token-Ring Header-Feld »Frame Control«

Kapitel 13 • Token-Ring

281

Filter auf (Protokoll-Feld/Parameter) ...

Offset

Wert (binär/hex)

MAC: Claim Token – CL_TK

01

00000011 = 0x03

MAC: Ring Purge

01

00000100 = 0x04

MAC: Active Monitor Present – AMP

01

00000101 = 0x05

MAC: Standby Monitor Present – SMP

01

00000110 = 0x06

Tab. 13.3: Filter auf Werte im Token-Ring Header-Feld »Frame Control«

 

          !  
          "  #  $ !   
      !   %          "   Der sog.

Eine noch genauere Inhaltsangabe folgt dann im eigentlichen Datenfeld des MAC-Protokolls: Die Funktion bzw. der Zweck eines MAC Frames wird mit der Angabe Major Vector ID (MVID) dargestellt, die eigentlichen Daten und Parameter werden jeweils als SubVector ID (SVID) dargestellt. Es sei verwiesen auf den Abschnitt »MAC Frames mit MVID und SVID«.

13.4.4 MAC Destination/Source Address Die innere Struktur der MAC-Adressen ist weiter hinten beschrieben im Abschnitt »Die logischen Adressen von Token-Ring«, auf den hier verwiesen wird.

13.4.5 FCS – Frame Check Sequence Die Prüfsumme liegt bei Token-Ring nicht am tatsächlichen Ende des Frames (anders als bei Ethernet), da jeder Token-Ring Frame damit rechnen muss, mehrfach während seiner Reise um den Ring abgestempelt zu werden. Im Feld Access Control sind von acht Bits immerhin sieben (!) für solche Markierungen gedacht (M-Bit, PPP-Bits, RRR-Bits). Im Feld Ending Delimiter sind die Markierungen Error Recognized und Intermediate Frame enthalten. Im Feld Frame Status sind die Quittungsstempel Address Recognized und Frame Copied enthalten (jeweils doppelt). Während das vor der FCS liegende Feld Access Control von der Prüfsumme wegen der veränderlichen Bits nicht erfasst wird, liegen die Felder Ending Delimiter und Frame Status hinter der FCS, damit die Prüfsumme nicht bei jeder Stempelmarkierung (bei jedem Wechsel eines Bits von »0« auf »1«) neu berechnet werden muss.

282

Das MAC-Protokoll: Funktionen und Filter

13.4.6 ED – Ending Delimiter Neben der allgemeinen Funktion, Beginn und Ende des Frames zu markieren (s.o. unter SD – Starting Delimiter), erfüllt der Ending Delimiter noch die Aufgabe, zwei Markierungs-Bits bzw. Stempelfelder bereitzustellen.

Abb. 13.7: Das Feld »Ending Delimiter« (Begrenzungszeichen)

Die Markierung Intermediate Frame (I-Bit) zeigt mit den Werten 0/1 an, ob der aktuelle Frame der letzte einer zusammenhängenden Serie ist (oder nicht); diese Funktion ist seit langem ungenutzt; sie war in der früheren Entwicklungsphase von Token-Ring im SNA-Umfeld von Bedeutung. Die Markierung Error Recognized (E-Bit) dient dazu, die Zahl der Fehlermeldungen bei Frame-Fehlern auf eine einzige zu begrenzen: Erkennt ein Adapter, dass ein vorüberkommender Frame defekt ist, setzt er das E-Bit auf »1«. Jeder weitere Adapter, der den Frame ebenfalls als defekt erkennt, kann aus dem gesetzten EBit schließen, dass der Fehler bereits gemeldet wurde, und unterlässt eine eigene Fehlermeldung an den Ring Error Monitor (REM). Siehe hierzu: Abschnitt 13.4.14 »Soft Errors«.

13.4.7 FS – Frame Status Token-Ring arbeitet mit einem Quittungssystem: Jeder Empfänger zeigt an, •

dass er einen Frame als an sich adressiert erkannt hat,

•

dass er diesen Frame in seinen Empfangspuffer kopiert hat.

Kapitel 13 • Token-Ring

283

Für beide Vorgänge gibt es ein eigenes Stempfelfeld (A/C-Bits): •

A-Bit = Address Recognized

•

C-Bit = Frame Copied

Die AC-Bits sind doppelt vorhanden; einerseits boten die acht Bits in Frame Status den Platz dafür, andererseits ist hierdurch eine gewisse Sicherheit gegenüber Verfälschungen geboten, da schließlich die Prüfsumme die AC-Bits nicht abdeckt.

Abb. 13.8: Das Feld »Frame Status« mit den AC-Bits

Die AC-Bits werden entweder vom tatsächlichen Empfängeradapter gesetzt, oder ersatzweise von den Source-Route Bridges, die zwischen dem Sender und dem Empfänger den Frame zwischen den Ringen vermitteln. Die verschiedenen Möglichkeiten, diese Bits zu setzen, sind wie folgt: AC-Bits

Bedeutung der AC-Bits aus der Sicht des Absenders

AC=00

Der Frame hat seinen Empfänger nicht gefunden. Entweder ist der Empfänger, so er denn im selben Ring siedelt, nicht eingeschaltet, oder der Frame wurde von keiner            !  "    " #     $%#         &  "  

Sollte definitiv klar sein, dass der Empfänger oder die Brücken hätten quittieren müssen, liegt bei Empfänger oder Brücke(n) ein Fehler vor. AC=10

Der Frame wurde erkannt, aber nicht kopiert. Der Empfänger (PC oder Bridge) hat zwar erkannt, dass der Frame an ihn adressiert war und dass er ihn hätte aufnehmen müssen, konnte dies aber nicht tun – vermutlich wegen einer    '(  ")   




Langsame Server oder überlastete Brücken geben oft diese Rückmeldung, verbunden mit zusätzlichen Soft Error Messages über Receiver Congestion an den Ring Error Monitor. Tab. 13.4: Die möglichen Bit-Kombinationen im Feld »Frame Status«

284

Das MAC-Protokoll: Funktionen und Filter

AC-Bits

Bedeutung der AC-Bits aus der Sicht des Absenders

AC=11

Der Frame wurde erkannt und kopiert. In diesem Falle ist nicht notwendig alles in Ordnung! Hier muss unterschieden werden: Siedelt der Empfänger im selben Ring, so bietet diese Rückgabe mit AC=11 tatsächlich die Gewähr, dass der Frame sicher ankam. Siedelt der Empfänger in einem anderen Ring, so ist nur gesichert, dass die erste        "      * !   !    $%#   )    " "  # "   "   "" (+))  )   ,!     -

      

     . &    

Eine echte Ende-zu-Ende-Quittung kann nur durch höhere Protokolle erreicht werden; dies sind typischerweise LLC (bei SNA-Sessions) oder Transportprotokolle wie TCP und SPX (bei Client-Server-Dialogen). AC=01

Achtung: Raubkopie! Die Angabe, dass der Frame zwar (von wem auch immer!) in den Eingangspuffer kopiert, aber von niemandem als entsprechend adressiert erkannt worden sei, stellt einen Widerspruch in sich dar. Wenn diese Bit-Kombination überhaupt vorkommt, dürfte ein Adapterfehler die Ursache sein. Dann ist es oft nur eine Frage der Zeit, bis Adapter im Ring einen der beiden  

    /

 ! 

  
 



  0   -)    )   (!"  12314

Tab. 13.4: Die möglichen Bit-Kombinationen im Feld »Frame Status«

Nicht jeder Analyzer ist in der Lage, Ereignisse im Zusammenhang mit dem Feld Frame Status anzuzeigen oder zu filtern. Die Beispiele in Abbildung 13.9 und Abbildung 13.10 wurden dem LANdecoder32 (Triticom) entnommen.

Abb. 13.9: LANdecocer32: Filtermaske für das »Frame Copied«-Bit

Abb. 13.10: LANdecoder32: Filtermaske für das »Address Recognized«-Bit

Fehler im Zusammenhang mit den AC-Bits wurden vom Autor in der Vergangenheit bei defekten TokenSwitches nachgewiesen; allerdings gehörten die jeweiligen Maschinen zu den ersten, frühen Generationen der TokenSwitches. In jüngster Zeit haben sich diese Fehler nicht mehr ergeben.

Kapitel 13 • Token-Ring

285

13.4.8 Information – LLC Data/MAC Data Der Frachtraum des Token-Ring Frames enthält entweder Nutzdaten, die via LLC befördert werden, oder das interne Verwaltungsprotokoll von Token-Ring, das MAC Protocol. Entsprechend wird unterschieden in MAC Frames und LLC Frames. Um welche Art von Inhalt bzw. Daten es sich jeweils handelt, wird im zweiten Frame-Oktett, dem Feld Frame Control, durch die FF-Bits markiert (s.o.).

13.4.9 MAC Frames mit MVID und SVID Das von Token-Ring intern verwendete MAC Protocol verwendet Frames, die stets nach demselben Muster aufgebaut sind: MVID – Major Vector ID Die übermittelte Hauptfunktion des MAC Frames wird mit einer sog. Major Vector ID (MVID) dargestellt. Die Position (der Offset) des jeweiligen MVID im MAC Frame ist immer gleich. SVID – SubVector ID Die eigentlichen Werte, die zu verarbeiten sind, werden jeweils mit einer sog. SubVector ID (SVID) dargestellt. Die Position (der Offset) des jeweiligen SVID im MAC Frame kann wechseln, da die Reihenfolge der SVIDs innerhalb eines Frames nicht vorgeschrieben ist. Was sind Vectoren? Jeder Parameter, der im MAC Frame den Empfängern übergeben wird, ist nach folgendem Strukturmuster aufgebaut: •

Vector Length Hier wird die Länge des gesamten MVID/SVID angegeben; der Längenwert umfasst die drei Parameter Vector Length, Vector ID und Vector Value.

•

Vector ID Dieser Wert kodiert die Funktion (MVID) bzw. die Art des Inhalts (SVID). So könnte ein MVID die Bedeutung »Report NAUN Change« haben, während ein folgender SVID ankündigt, dass der nachfolgende Vector Value die neue MAC-Adresse des Nachbarn, die sog. »NAUN Address«, beinhaltet.

•

Vector Value Hier sind die eigentlichen Daten enthalten, die es zu übermitteln gilt, in unserem Beispiel etwa die angekündigte NAUN Address.

Diese abstrakte und sehr variable Darstellungsform wechselnder Daten wurde mit ASN.1 (Abstract Syntax Notation 1) bekannt.

286

Das MAC-Protokoll: Funktionen und Filter

Abb. 13.11: MAC-Frames mit MVID und SVID

Die verschiedenen MAC Frames enthalten jeweils eine festgelegte Anzahl bestimmter SVID-Werte; eine vollständige Tabelle aller möglichen MVIDs und SVIDs folgt im nächsten Abschnitt.

13.4.10 Filter auf MVIDs Bereits weiter oben wurden die Möglichkeiten beschrieben, Filter auf die Werte von Frame Control und damit auf das MAC Protocol zu setzen. Es können aber auch Filter auf die MVIDs gesetzt werden, deren einer in jedem MAC-Frame als Inhaltsangabe bzw. Funktionsbestimmung enthalten ist. Die MVIDs sind wesentlich genauer als Filter verwendbar als die Werte aus Frame Control, woraus sich folgende Praxis ergibt: •

Filter auf Frame Control werden verwendet, wenn man alle MAC-Frames sehen will, ohne weiter einschränken zu wollen.

•

Filter auf MVID werden gesetzt, wenn man genau weiß, wonach man sucht, und wenn ein Filter auf Frame Control zu grob bzw. zu ungenau wäre.

Filter auf die SVID sind nicht zuverlässig möglich, da ihre Reihenfolge im Frame und damit ihre absolute Lage (Position, Offset) vom Standard nicht vorgeschrieben ist und darum auch tatsächlich wechselt; daraus ergibt sich ihre Unbrauchbarkeit für Filter. Filter auf MAC-Frame MVID ...

Offset

Wert (hex)

MVID: Response

17

0x00

MVID: Beacon – BCN

17

0x02

MVID: Claim Token – CL_TK

17

0x03

MVID: Ring Purge

17

0x04

Tab. 13.5: MVID-Werte im MAC Protocol von Token-Ring

Kapitel 13 • Token-Ring

287

Filter auf MAC-Frame MVID ...

Offset

Wert (hex)

MVID: Active Monitor Present – AMP

17

0x05

MVID: Standby Monitor Present – SMP

17

0x06

MVID: Duplicate Address Test – DAT

17

0x07

MVID: Lobe Media Test

17

0x08

MVID: Transmit Forward

17

0x09

MVID: Remove Ring Station

17

0x0B

MVID: Set Parameters-1/Change Station Parameters

17

0x0C

MVID: Set Parameters-2/Initialze Ring Station

17

0x0D

MVID: Request Ring Station Address

17

0x0E

MVID: Request Ring Station State

17

0x0F

MVID: Request Ring Station Attachment

17

0x10

MVID: Request Initialization

17

0x20

MVID: Report Ring Station Address

17

0x22

MVID: Report Ring Station State

17

0x23

MVID: Report Ring Station Attachments

17

0x24

MVID: Report New Active Monitor

17

0x25

MVID: Report NAUN Change

17

0x26

MVID: Report Poll Failure

17

0x27

MVID: Report Active Monitor Error

17

0x28

MVID: Report Soft Error (Isolating/Non-Isolating)

17

0x29

MVID: Report Transmit Forward

17

0x2A

Tab. 13.5: MVID-Werte im MAC Protocol von Token-Ring MAC Frame SVID

Offset

Wert (hex)

SVID: Beacon Type (Type Codes 0x01-04)

(variabel)

0x01

SVID: NAUN Address

(variabel)

0x02

SVID: Local Ring Number

(variabel)

0x03

SVID: Assign Physical Drop Number (Location)

(variabel)

0x04

SVID: Soft Error Report Timer

(variabel)

0x05

SVID: Enabled Function Classes

(variabel)

0x06

SVID: Allowed Access Priority (Type Codes 0x00-03)

(variabel)

0x07

SVID: Authorized Environment

(variabel)

0x08

SVID: Correlator

(variabel)

0x09

Tab. 13.6: SVID-Werte im MAC Protocol von Token-Ring

288

Das MAC-Protokoll: Funktionen und Filter

MAC Frame SVID

Offset

Wert (hex)

SVID: Address of Last Neighbor Notification

(variabel)

0x0A

SVID: Physical Location (Physical Drop Number)

(variabel)

0x0B

SVID: Response Code

(variabel)

0x20

SVID: (Reserved)

(variabel)

0x21

SVID: Product Instance ID

(variabel)

0x22

SVID: Ring Station Microcode/Software Level

(variabel)

0x23

SVID: Wrap Data

(variabel)

0x26

SVID: Frame Forward

(variabel)

0x27

SVID: Ring Station Status Vector

(variabel)

0x29

SVID: Group Address

(variabel)

0x2B

SVID: Functional Address

(variabel)

0x2C

SVID: Isolating Error Counts

(variabel)

0x2D

SVID: Non-Isolating Error Counts

(variabel)

0x2E

SVID: Active Monitor Error (Type Codes 0x01-03)

(variabel)

0x30

SVID: Extended Length Sub-Vector

(variabel)

0xFF

Tab. 13.6: SVID-Werte im MAC Protocol von Token-Ring

Einige der MVIDs werden mittels spezieller SVIDs noch weiter zergliedert, darunter                 &      '  % ()#&              *    '  %  +)#& SVID 0x01 »Beacon Type« Codes

Offset

SVID Code (hex)

During Configuration

(variabel)

0x01

Signal Loss (= »J« Symbols)

(variabel)

0x02

TNT expired/Claim Token Frames Received

(variabel)

0x03

TNT expired/No Claim Token Frames Received

(variabel)

0x04

Tab. 13.7: SubCodes für SVID 0x01 »Beacon Type« SVID 0x2D »Isolating Error Counts« Type Codes

Offset

Inhalt

Octet 0 = Line Error

(var.)

Zähler-Wert

Octet 1 = Internal Error

(var.)

Zähler-Wert

Octet 2 = Burst Error

(var.)

Zähler-Wert

Octet 3 = A/C Error

(var.)

Zähler-Wert

Tab. 13.8: SubCodes für SVID 0x2D »Isolating Error Counts«

Kapitel 13 • Token-Ring

289

SVID 0x2D »Isolating Error Counts« Type Codes

Offset

Inhalt

Octet 4 = Abort Delimiter

(var.)

Zähler-Wert

Octet 5 = (reserved)

(var.)

Zähler-Wert

Tab. 13.8: SubCodes für SVID 0x2D »Isolating Error Counts« SVID 0x2E »Non-Isolating Error Counts« Type Codes

Offset

Inhalt

Octet 0 = Lost Frame Error

(var.)

Zähler-Wert

Octet 1 = Receive Congestion

(var.)

Zähler-Wert

Octet 2 = Frame Copied Error

(var.)

Zähler-Wert

Octet 3 = Frequency Error

(var.)

Zähler-Wert

Octet 4 = Token Error

(var.)

Zähler-Wert

Octet 5 = (reserved)

(var.)

Zähler-Wert

Tab. 13.9: SubCodes für SVID 0x2E »Non-Isolating Error Counts« SVID 0x30 »Active Monitor Error« Type Codes

Offset

Wert (hex)

Active Monitor Error

(var.)

0x01

Duplicate Active Monitor

(var.)

0x02

Duplicate Address

(var.)

0x03

Tab. 13.10: SubCodes für SVID 0x30 »Active Monitor Error«

13.4.11 Neuer Adapter im Ring Will sich ein Adapter im Ring anmelden, durchläuft er folgende Arbeitsschritte: •

Phase 1:    

•

Phase 2: Lobe Media Check

•

Phase 3: Relais / Ring Speed

•

Phase 4: Monitor Check

•

Phase 5: Address Verification

•

Phase 6: Participate In Ring Poll

•

Phase 7: Request Initialization

Zunächst werden die Vorgabe-Einstellungen aktiviert, die in der Adapter-Hardware enthalten sind. Dann erfolgt der Kabeltest: Es werden Frames beliebigen Inhalts (Wrap Data) gesendet; da das Relais am Ringleitungsverteiler (RLV) noch geschlossen ist, kommen alle Frames zum Adapter zurück. Sind die eingehenden Frames mit den ausgehenden identisch, ist klar, dass das Kabel einwandfrei ist.

290

Das MAC-Protokoll: Funktionen und Filter

Sodann wird das Relais am RLV geöffnet und der Ring bzgl. Frequenz, Token und Active Monitor untersucht; ist binnen 18 Sekunden kein AMP Frame (Active Monitor Present) zu empfangen, wird der neue Adapter selber Active Monitor; stimmt die Frequenz nicht, verlässt der Adapter den Ring wieder (wobei bereits kurzzeitig Beacon durch den nachfolgenden Adapter ausgelöst worden sein kann). Ist diese Art der physikalischen Zugriffe auf den Ring gesichert, erfolgt die logische Absicherung, indem die Einmaligkeit der eigenen MAC-Adresse mittels Duplicate Address Test (DAT, s.u. 13.4.12) sichergestellt wird. Ist auch der DAT gut verlaufen, nimmt der Adapter am Ring Poll bzw. NAUN Process teil (siehe 13.4.13). Hiermit reiht er sich logisch in die Ringreihenfolge aller Adapter ein. Ist auch das geschehen, fragt der neue Adapter nach einem Ring Parameter Server (RPS), um ggf. neue Werte für Ringparameter zugewiesen zu bekommen, die vom Adapter-Vorgabewert abweichen. Auf diese (heute selten gewordene) Weise könnte dem Adapter eine neue logische Adresse (LAA) zugewiesen werden oder neue Timer-Werte, etwa für die maximale Umlaufzeit des Tokens (siehe 13.4.20).

13.4.12 DAT/Duplicate Address Test Sobald ein Token-Ring-Adapter das Relais am Ringleitungsverteiler geöffnet hat, prüft er zunächst die Ring-Geschwindigkeit (Frequenz) und die Anwesenheit eines Active Monitors bzw. eines Tokens. Sind diese Lebenszeichen des Ringes korrekt gegeben, führt der Adapter einen Duplicate Address Test durch: Um sicherzustellen, dass kein zweiter Adapter mit derselben (logischen) MACAdresse im Ring bereits aktiv ist, sendet er zwei MAC-Frames, die sowohl als MAC Destination Address wie auch als MAC Source Address seine eigene MACAdresse enthalten. Kommen beide DAT-Frames zurück, ohne mit Empfangsquittung abgestempelt zu sein (AC=00), ist klar, dass der neue Adapter eine eindeutige, einmalige Adresse hat; der neue Adapter bleibt im Ring und nimmt am NAUN-Prozess teil und fragt nach dem Ring Parameter Server (RPS). Kommt einer der beiden DAT-Frames mit abgestempeltem Quittungsfeld zurück (AC=11 oder AC=10), geht der neue Adapter davon aus, dass bereits ein zweiter Adapter seine Adresse hat, und verlässt den Ring wieder (sofort und unverzüglich).

13.4.13 NAUN Process/Ring Poll Process Ohne Token kann kein Token-Ring-Adapter Daten senden. Also muss die Anwesenheit des Token überwacht und garantiert werden. Hierfür ist der sog. Active Monitor zuständig. Da ein Ausfall des Active Monitors seinerseits den Wegfall

Kapitel 13 • Token-Ring

291

des Tokens bedeuten könnte, überwachen alle anderen Adapter als sog. Standby Monitors ihrerseits den Active Monitor. Fällt dieser aus, überninmmt einer der Standby Monitors die Rolle des Active Monitor.

,                      -      ."    &  +          /+01   2"     ( "         +0  "  3 ! /1   +4  C000FF.FFFFFF Filter auf (Protokoll-Feld/Parameter) ...

Offset

Wert (hex)

Token-Ring Multicast Address

02

C000FF.FFFFFF

Tab. 13.11: Filter auf Token-Ring Multicasts, etwa AMP/SMP-Meldungen

Da jeder Token-Ring Frame – so auch AMP/SMP – mit einem leeren Stempelfeld für die Empfangsquittung losgeschickt wird, erkennt der nächst nachfolgende Adapter mittels des noch leeren Stempelfeldes (die sog. »AC«-Bits für 



   
  !1              '   &%       '   "             ) 5 $ 676 8 "  # $
"%# 

Der Active Monitor erhält sodann seinen AMP-Frame abgestempelt zurück, nimmt ihn vom Ring und gibt das Token weiter. Daraufhin nimmt sich der nächst nachfolgende Adapter (der eben noch den Empfang von AMP quittiert hatte) das freie Token und sendet seinerseits Standby Monitor Present (SMP). Auch hier bleibt beim Abschicken das Stempelfeld für die Empfangsquittung leer (AC=00), woraufhin der nächst nachfolgende Adapter erkennt, dass dieser SMP-Frame noch von niemandem gesehen wurde (er also der im Ring stromabwärts liegende Nachfolger des Absenders sein muss). Er stempelt sodann das Quittungsfeld ab (AC=11) und merkt sich die Absenderadresse = NAUN-Adresse. So geht es den Ring reihum, bis der Active Monitor seinerseits einen SMP-Frame erhält, der noch nicht als »erhalten« abgestempelt wurde (also AC=00). In diesem Moment ist der Ring Poll Process oder NAUN Process beendet. Wird der NAUN Process nicht abgeschlossen, so wird der Active Monitor einen Fehler melden: Neighbor Notification Incomplete – ein schwerer Fehler. Der NAUN-Prozess bietet bei der Analyse einige wichtige Vorteile: •

Die physikalische Reihenfolge der Adapter ist sofort offenbar.

•

Fehlerfeldungen enthalten immer Absender- und Vorgängeradresse.

Mit einem Filter auf die sog. MAC-Frames (0x0X, Offset=1) liest der Analyzer nur noch das interne Gespräch der Adapter mit; sofort nach spätestens sieben Sekunden hat man die Liste der im lokalen Ring angeschlossenen Adapter samt ihrer tatsächlichen, physikalischen Reihenfolge.

292

Das MAC-Protokoll: Funktionen und Filter

Der Wert »0X« in der folgenden Filterbeschreibung besagt: Die ersten vier Bits müssen auf »0« stehen, der Wert der letzten vier Bits ist gleichgültig. Das hat mit der Struktur des Token-Ring Protokollfelds Frame Control zu tun, denn nur der Wert des zweiten Bits zeigt an, ob es sich um MAC-Frames (»0000xxxx«) oder um LLC-Frames (»0100xxxx«) handelt. Filter auf (Protokoll-Feld/Parameter) ...

Offset

Wert (hex)

Alle Token-Ring MAC Frames

01

0X

Tab. 13.12: Filter auf sämtliche MAC-Frames von Token-Ring

Weiterhin erhält man mit diesem Filter alle Fehlermeldungen, die von den Adaptern gesendet werden: Und jede Fehlermeldung enthält die MAC-Adresse des Absenders, der den Fehler entdeckt hat, sowie dessen NAUN-Adresse, über die der Ort des Fehlers eingegrenzt werden kann: Physikalische Defekte an TokenRing Frames können nur aufgetreten sein zwischen dem meldenden Adapter sowie dem Adapter seines im Ring stromaufwärts liegenden Nachbarn (NAUN).

13.4.14 Soft Errors/Fehlermeldungen Token-Ring unterscheidet zwischen sog.      &   9       &         &    :   :       0   Soft Errors sind »weiche Fehler«, die den Bestand des Ringes nicht gefährden oder die von den Adaptern jeweils selber korrigiert werden. Soft Errors sind täglich zu beobachten bei Relaisschaltungen am Ringleitungsverteiler (mechanisch und elektrisch) und meistens harmlos. Beacon wird gemeldet, wenn über längere Zeit keine Datenpakete mehr den Ring passieren, wenn das Token ausbleibt und/oder wenn das Freizeichen (idle symbol) nicht mehr zu hören ist. Beacon wird also gemeldet, wenn ein Hardware-Ausfall den Ring funktionsunfähig gemacht hat. Im Falle von Beacon führen die beiden Adapter, die links und rechts der Schadensstelle sitzen, nach und nach offline einen Selbsttest bzw. Kabeltest durch; wurde hierbei der Hardware-Fehler gefunden, bleibt der schadhafte Adapter »draußen«, wodurch der Ring wieder arbeitsfähig wird. Wurde der Fehler nicht gefunden (Adapter und Kabel sind fehlerfrei), so lag es auch nicht an den Adaptern und/oder Kabeln, sondern am Ringleitungsverteiler dazwischen. In diesem Falle hilft nichts mehr, das Beacon läuft endlos weiter, und es hilft nur noch das Abschalten aller Geräte und das Austauschen des Ringleitungsverteilers. In jedem dieser Fälle ging das Token schon verloren oder sein Verlust droht(e) unmittelbar.

Kapitel 13 • Token-Ring

293

Bei diesen und ähnlichen Fällen besteht die erste Reaktion eines jeden TokenRing-Adapters darin, ein neues Token bzw. dessen Absicherung zu verlangen: Claim Token heißt diese Meldung. Dies ist nicht unähnlich dem Ruf »neue Karten!« oder »neuer Geber!« bei einer Pokerrunde, wenn ein Spieler den Karten und/oder dem Geber nicht mehr traut. So auch hier, wenn ein Adapter dem Token und/oder dem Active Monitor nicht mehr traut. Auch bei Token-Ring misstraut jeder jedem und ist extrem nervös gegenüber kleinsten Unregelmäßigkeiten. Claim Token kann gesendet werden, wenn der Verlust des Active Monitors festgestellt wurde, der Verlust des Tokens oder ein Defekt des Tokens. Letzteres geschieht oft in Folge von Relais-Schaltungen am Ringleitungsverteiler (RLV): Wenn der Active Monitor nicht sofort mit der Ausgabe eines neuen Tokens auf einen solchen Fehler reagiert, verlangen die anderen sofort: Claim Token! Stellt sich nach dem Ruf Claim Token heraus, dass der bisherige Active Monitor nicht mehr präsent ist bzw. kein neues Token generiert, nimmt jeder Claim Token meldende Adapter an, dass er nun selber die Rolle des Active Monitors zu übernehmen hat. Um vom Zustand des Standby Monitors zu wechseln in den Zustand des Active Monitors, müssen drei eigene Claim Token Frames um den Ring gelaufen sein, ohne dass ein anderer Adapter widersprochen hätte. Widerspruch? Token-Ring Adapter können sich im Falle der Abwesenheit eines Active Monitors (AM) darum streiten (Contention), wer denn nun AM werden soll. In diesem Fall verwirft ein Adapter im Contention Mode die Claim Token Frames anderer, sofern er selber eine numerisch höhere MAC-Adresse hat. Im Contention-Falle übernimmt also der Adapter die AM-Funktion, der die höchste MAC-Adresse hat. Dies sind oft Source-Routing-Bridges. Da jedoch die Werkseinstellung der Adapter überwiegend Non-Contention Mode ist, übernimmt genau der Adapter die AM-Funktion, der den Fehler zuerst entdeckte bzw. der zuerst Claim Token meldete. Auf diese Weise wird meistens der stromabwärts siedelnde Nachfolger des bisherigen AM der neue AM. Gibt es einen neuen AM, so ist seine erste Aufgabe, ein neues Token zu generieren. Folgerichtig benötigen die Adapter für die Claim Token Frames übrigens ausnahmesweise kein Token – wie sollten sie auch auf eines warten, wenn sie ja den Verlust des Tokens melden wollen? Vor jeder Ausgabe eines neuen Token jedoch ergeht vom AM die Anweisung an alle anderen Adapter, sämtliche Übertragungen einzustellen: Ring Purge = »Ring frei zur nächsten Runde«, sozusagen. Claim Token, Ring Purge und Beacon sind sogenannte Ring Recovery MAC Frames, mit denen ein außer Funktion geratener Ring gerettet werden soll.

294

Das MAC-Protokoll: Funktionen und Filter

13.4.15 Isolating/Non-Isolating Soft Errors Die sog. Soft Errors sind unterteilt in Isolating Errors und Non-Isolating Errors. Die Grundidee war, Fehler grundsätzlich wie folgt zu unterscheiden: •

Bei Isolating Errors ist der Ort des Fehlers eingrenzbar,

•

bei Non-Isolating Errors dagegen nicht.

Folgende Fehlerzähler wurden festgelegt: Isolating Errors Counts Line Error Fehler im physikalischen Differential Manchester Code oder Fehlen der Prüfsumme (FCS). Der erkennende Adapter stopft die Schadensstelle im Frame aus und markiert den Frame mit dem Error Recognized Bit. Der Fehler muss zwischen Vorgänger und Melder eingetreten sein und kann somit örtlich isoliert werden. Burst Error Abwesenheit von Pegelwechseln im Differential Manchester Code über mindestens fünf Halb-Bit-Zeiten hinweg (Burst Five Condition). Der erkennende Adapter stopft die Schadensstelle aus und markiert den Frame mit dem Error Recognized Bit. Der Fehler muss zwischen Vorgänger und Melder eingetreten sein und kann somit örtlich isoliert werden. AC Bit Error Ein Adapter erhält mehrere AMP oder SMP Frames (Active/Standby Monitor Present), bei denen die AC-Bits auf »00« stehen (Adress Recognized/Frame Copied). Dies deutet darauf hin, dass der stromaufwärts liegende Adapter die AC-Bits nicht korrekt von AC=00 auf AC=11 umsetzen kann. Der NAUN-Adapter dürfte also defekt sein. Der Fehler muss beim Vorgänger des Melders eingetreten sein und kann somit örtlich isoliert werden. Internal Error Ein Adapter hat beim Selbsttest einen Fehler an sich selbst entdeckt. Der erkennende Adapter meldet dies immer nur über sich selbst, womit der Fehler örtlich isolierbar ist. (Die NAUN-Adresse ist hierbei folglich ohne Belang.)

Kapitel 13 • Token-Ring

295

Abort Error Eine Übertragung musste vor regulärer Beendingung des Frames abgebrochen werden; dies wurde sodann mit Sendung einer Abort Sequence kenntlich gemacht. Diese Abort Sequence besteht nur aus einem Starting Delimiter und einem Ending Delimiter, nichts sonst (es sind also keinerlei Daten oder Adressierungen enthalten). Der erkennende Adapter meldet dies immer über sich selbst, womit der Fehler örtlich isolierbar ist. (Die NAUN-Adresse ist hierbei folglich ohne Belang.) Non-Isolating Error Counts Lost Frame Ein Adapter erhält einen eigenen Frame, den er selber in den Ring sendete, nicht vollständig zurück; er ging also ganz oder teilweise während des Umlaufs verloren. Da der Ort des Verlusts aus der Sicht des sendenden Adapters nicht erkennbar ist, handelt es sich um einen örtlich nicht isolierbaren Fehler. Frame Copied Ein Adapter erhält einen an ihn adressierten Frame, in dem die AC-Bits nicht auf »00« stehen. Das bedeutet, dass ein anderer Adapter den Erhalt bereits bestätigt hat, oder aber dass der Absender den Frame nicht mit AC=00, sondern mit AC=11 gesendet hat. Da der Adapter, der die AC-Bits auf »11« gesetzt hat, aus der Sicht des meldenden Adapters nicht erkennbar ist, handelt es sich um einen örtlich nicht isolierbaren Fehler. Ursache könnte entweder eine doppelte MAC-Adresse sein (was wegen des DATTests unwahrscheinlich ist), oder ein fremder Adapter ist defekt und markiert willkürlich Frames auf diese Weise. Receive Congestion Ein Adapter erhält einen an ihn adressierten Frame, kann ihn aber wegen Pufferüberlaufs nicht in seinen Eingangsspeicher kopieren. Da diese Meldung von dem an Stau leidenden Adapter selber kommt, ist der Fehler räumlich isolierbar, weswegen die Einordnung unter »non-isolating errors« nicht nachvollziehbar ist. Token Error Dieser Fehler wird ausschließlich vom AM gemeldet, wenn eine der folgenden Bedingungen gegeben ist: •

Es wurde ein Token gesehen mit Priorität größer Null und gesetztem MonitorBit (M=1).

•

Es wurde ein Frame gesehen mit gesetztem Monitor-Bit (M=1).

296

Das MAC-Protokoll: Funktionen und Filter

•

Es wurde kein Token oder Frame seit 10 Millisekunden empfangen.

•

Der Starting Delimiter bzw. die Token Sequence weisen eine Code-Verletzung dort auf, wo sie nicht auftreten darf. (Code Violations dürfen nur in fest vorgegebener Weise im Starting Delimiter und dem Ending Delimiter auftreten.)

Da aus der Sicht des AM nicht erkennbar ist, welche Ursache jeweils die Bedingung hat eintreten lassen, handelt es sich um einen örtlich nicht isolierbaren Fehler. Frequency Error Ein Adapter empfängt ein Signal mit einer falschen Frequenz. In aller Regel wird dies verursacht durch einen neuen Adapter, der zwischen ihm und seinem NAUN (Vorgänger im Ring) versucht, in den Ring zu kommen – und zwar mit einer falschen Ringgeschwindigkeit (4 Mbps statt 16 Mbps, oder umgekehrt). Da die Ursache dieser Meldung zweifelsfrei zwischen Melder und dessen NAUN liegt, ist der Fehler räumlich isolierbar, weswegen die Einordnung unter Non-Isolating Errors nicht nachvollziehbar ist.

13.4.16 Ring Error Monitor (REM) Sämtliche Fehlermeldungen werden an die Funktionsadresse des Ring Error Monitors gesendet (MAC=C00000.000008).

Abb. 13.12: Eine typische Token-Ring Fehlermeldung, die an den Ring Error Monitor adressiert ist.

Kapitel 13 • Token-Ring

297

In der Abbildung 13.12 ist zu sehen, wie ein Adapter erheblichen Pufferüberlauf bzw. Annahmestau meldet: 42 Frames konnte dieser Adapter zuletzt nicht mehr annehmen.

13.4.17 Ring Purge Mit dem Ring Purge MAC Frame teilt der Active Monitor allen anderen Stationen mit: »Ring frei [machen] zur nächsten Runde.« Alle anderen Ringstationen müssen unverzüglich sämtliche Übertragungen einstellen. Nach dem Ring Purge gibt der AM ein neues Token auf den Ring. Der Active Monitor führt den Ring Purge unter folgenden Bedingungen durch: •

Unmittelbar nach Übernahme der Funktion des Active Monitor.

•

Bei Verlust des Token.

•

Bei Erkennen defekter Frames.

Für das Generieren eines Ring Purge Frames wird kein freies Token benötigt (es wird nicht gewartet); schließlich wird ja die Ausgabe eines neuen Token vorbereitet. Da eine Ursache von Ring Purge eine länger anhaltende Ringstörung sein kann (Störstrahlungen, Wackelkontakte etc.), sendet der AM so lange Ring Purge Frames, bis einer der Frames unversehrt wiederkehrt. Die Ring Purge Frames werden im Abstand von 20 Millisekunden gesendet. Der Ring Purge Process kommt einer Rücksetzung des Token-Ring-Kreislaufs gleich. Nach einem Ring Purge erfolgt eine Meldung an den Ring Error Monitor (REM, siehe 13.4.16) oder Configuration Report Server (CRS, siehe 13.4.20).

13.4.18 Beacon Process Der Beacon Process ist der letzte Weg, einen andauernden Hardware-Fehler im Ring zu behandeln und eine mögliche Heilung einzuleiten. Beacon Frames werden von einer Station gesendet, wenn eine Störung auf der Eingangsleitung festgestellt wird und damit keine Frames mehr von der NAUN-Station erhalten werden. Die Beacon Frames werden so lange gesendet, bis der Fehler behoben ist; das Intervall beträgt 20 Millisekunden. Es gibt vier verschiedene Typen von Beacon Frames, jeweils gekennzeichnet mit einer eigenen Subvector ID: SVID 01h = Beacon Type (siehe Tabelle 13.7: SubCodes für SVID 0x01 »Beacon Type«). Da im Beacon Frame die Adresse der NAUN-Station angegeben wird, ist einem Ring Error Monitor (REM) oder einem LAN-Analysator sofort ersichtlich, zwischen welchen zwei Stationen der Hardware-Fehler aufgetaucht ist. Dies sichert kürzestmögliche Reaktionszeit.

298

Das MAC-Protokoll: Funktionen und Filter

Im Folgenden wird angenommen, dass eine Station S Beacon Frames sendet, die Vorgänger-Station wird als S-1 bezeichnet, die Nachfolgerstation als S+1. 1. Möglichkeit Im günstigsten Fall erreichen die Beacon Frames von Station S die besagte NAUN-Station S-1, die ihre eigene MAC-Adresse als NAUN-Adresse im Beacon Frame erkennt. Daraus schließt sie, dass der Hardware-Fehler an ihrer Ausgangsleitung liegen muss. Nach Erhalt von acht Beacon Frames in Folge löst sich die NAUN-Station S-1 vom Ring und führt einen Lobe Media Test durch. Sollte dieser Test einen Fehler im Anschlusskabel ergeben, bleibt die NAUN-Station S-1 »draußen«, und der Token-Ring ist geheilt: Die Beacon Frames sendende Station S empfängt nun die eigenen Beacon Frames und erkennt daran, dass der Ring wieder geschlossen ist. Das Beaconing wird beendet, und der Monitor Contention Process bzw. das Claim Token wird eingeleitet (siehe 13.4.19). 2. Möglichkeit Die NAUN-Station S-1 hat den Lobe Cable Test mit Erfolg durchgeführt: Das Anschlusskabel ist fehlerfrei. Hierauf kehrt die NAUN-Station S-1 in den Ring zurück und die Beacon Frames sendende Station S geht nun ihrerseits davon aus, dass ihr Lobe-Kabel defekt ist. Sie trennt sich vom Ring und führt den Lobe Cable Test durch. Für den Fall, dass ihr Lobe-Kabel fehlerhaft ist, bleibt die Station S »draußen«, und die Nachfolge-Station S+1 beginnt den Monitor Contention Process. 3. Möglichkeit Der Lobe Cable Test der ursprünglich Beacon Frames sendenden Station S war gleichfalls erfolgreich und die Station S kehrt in den Ring zurück. In diesem Fall beginnt die nachfolgende Station S+1, Beacon Frames zu senden – und zwar endlos. Nur menschliches Eingreifen kann dann noch helfen. Wenn der Beacon Process nach 26 Sekunden nicht zu einer Selbstheilung des Ringes geführt hat, läuft das Beaconing endlos weiter.

13.4.19 Claim Token/Monitor Contention Process Die Arbeitsweise des Token-Ringes setzt zwingend voraus, dass eine Ringstation (genauer: ein Token-Ring-Adapter) die Funktion des Active Monitor ausübt, die ihrerseits das Token garantiert. Die erste Station, die im Ring eingeschaltet wird, übernimmt immer auch zunächst die Funktion des Active Monitor. (Siehe 13.4.11, Station Initialization Process). Stellt ein Standby Monitor (SM) im laufenden Betrieb fest, dass eine Störung des Active Monitor (AM) vorliegt (z.B. weil kein Token mehr bereitgestellt oder weil kein AMP-Frame mehr empfangen wurde), löst dies sofort bei der erkennenden

Kapitel 13 • Token-Ring

299

Station das Senden eines MAC Frames mit der Meldung Claim Token aus, was entweder direkt das Verlangen nach einem Token ausdrückt oder indirekt das Verlangen nach einem Active Monitor. Mit dem Claim Token MAC Frame wird der Monitor Contention Process eingeleitet, der Wettbewerb um die Übernahme der Funktion des Active Monitors. Die Claim Token MAC Frames werden im Abstand von 20 Millisekunden gesendet. Theoretisch könnte jede Ringstation Active Monitor werden, sofern der jeweilige Adapter auf Teilnahme am Monitor Contention Process eingestellt ist. Die übliche Vorgabe ist die Nicht-Teilnahme (Non-Contention). In jedem Fall aber nimmt die Station an dem Verfahren teil, die den Active Monitor Error oder sonstigen Ringfehler festgestellt und den ersten Claim Token MAC Frame gesendet hat. Jede Station, die am Monitorwettbewerb teilnimmt, überprüft in den umlaufenden Claim Token MAC Frames die darin enthaltene Absenderadresse; ist die eigene MAC-Adresse höher als die des Absenders, wird die eigene Adresse in den Claim Token MAC Frame geschrieben (anstelle der vorhandenen). Erkennt die Station, die den Claim Token MAC Frame gesendet hat, eine andere (nämlich höhere) Absenderadresse im wiederkehrenden Claim Token MAC Frame (und nicht die eigene), kann sie nicht mehr Active Monitor werden; sie nimmt am Monitorwettbewerb nicht länger teil. Neuer Active Monitor wird genau die am Contention-Verfahren teilnehmende Station, deren MAC-Adresse drei Mal hintereinander nicht von einer anderen Station überschrieben wurde: Diese Station wechselt dann vom Standby Monitor Status in den Active Monitor Status. Dieser Wechsel des Active Monitors wird an den Configuration Report Server (CRS) mit Report New Monitor gemeldet; sodann wird der Ring bereinigt (Ring Purge MAC Frame); danach wird ein neues Token ausgebracht. Sollte der vorherige Active Monitor ausgefallen sein, wird die dem alten Active Monitor ursprünglich nachfolgende Station noch NAUN Change melden.

13.4.20 Ring Parameter Server (RPS)/Configuration Report Server (CRS) Weiter oben wurde davon gesprochen, dass der Token-Ring Teile der Funktionalität des alten SNA-FEPs übernommen hatte. Dies wird an manchen MVIDs deutlich, die für Dialoge zwischen RPS/CRS und beliebigen Adaptern reserviert sind. So sind die MVIDs »Request Ring Station ...« und »Report Ring Station ...« (MVID 0x0E-0x024) Überreste aus alten SNATagen: Diese Abfragen werden vom RPS/CRS durchgeführt, der hier letztlich als Ersatz des vormaligen SNA Front End Processors (FEP) arbeitet.

300

Vorgehensweise in der Analyse

Diese RPS/CRS-Abfragen werden heute in der Regel nur noch durchgeführt ... •

bei Eintritt eines neuen Adapters in den Ring, da bei dieser Gelegenheit immer nach einem RPS gesucht wird;

•

in Token-Ring-LANs, die tatsächlich noch SNA benutzen;

•

in Token-Ring-LANs, in denen der OS/2 LAN Network Manager von IBM betrieben wird;

•

durch Bridge/Router, die mit den werksseitigen Voreinstellungen in Betrieb genommen werden und die darum eher versehentlich als RPS/CRS arbeiten.

Jeder Token-Ring-Adapter, der neu in den Ring kommt, sucht den RPS, um ihn nach Ringparametern zu fragen. Ist kein RPS da bzw. antwortet kein RPS, arbeitet der Adapter mit den Voreinstellungen bzw. mit den Parametern weiter, mit denen er sich zuvor (außerhalb des Ringes) initialisiert hat. Der einzige nennenswerte Parameter, den es per RPS zu korrigieren lohnen würde, ist der Wert für die maximale Umlaufzeit des Token. Diese Möglichkeit war in den 80er Jahren interessant, als immer mehr Stationen in immer größeren Ringen Platz fanden, was zu immer längeren Kabelwegen und zu immer größerer Umlaufzeit des Token führte. Wo heute noch Token-Ring betrieben wird, spielt das definitiv keine Rolle mehr, da die Ringe längst in kleinere Segmente zerlegt wurden. Nicht zuletzt Routing und TokenSwitching haben hierzu beigetragen.

13.5

Vorgehensweise in der Analyse Die Vorgehensweise bei der Token-Ring-Analyse hängt einerseits mit dem aktuellen Szenario zusammen; andererseits wird in jedem Fall mit den zuvor beschriebenen Filtern gearbeitet.

13.5.1 Eingrenzung von Ort und Ursache LAN-Analyse ist methodisch gesehen in aller Regel der Ausschluss aller möglicher Fehlerursachen, bis am Ende nur noch eine übrig bleibt: Isolation von •

Ort des Geschehens und

•

Ursache des Fehlers

durch direkten Beweis (Einschluss) und/oder durch indirekten Beweis (Ausschluss). Siehe hierzu das Kapitel »Grundlagen der Methodik«, das Vorgehensweisen entwickelt, die für alle LAN-Topologien gleichermaßen gelten und die mit den Mitteln herkömmlichen Netzwerkmanagements gut umgesetzt werden können. Token-Ring bietet aber noch darüber hinausgehende Möglichkeiten, die sämtlich mit den Eigenarten des MAC Protocols zusammenhängen.

Kapitel 13 • Token-Ring

301

13.5.2 Ort des Fehlers in der Ring-Topologie Der Ort des Fehlers wird bei Token-Ring anders eingegrenzt als bei Ethernet. Der Grund ist: Während sich Ethernet-Adapter niemals selber mit Fehlermeldungen bemerkbar machen, plappern die Token-Ring-Adapter laufend mit Meldungen auf den Ring mit Aussagen •

über ihren eigenen Zustand,

•

über den Zustand des Ringes und

•

über den Zustand der vorbeikommenden Datenpakete.

Die Gesamtheit dieser Meldungen und der entsprechenden Regeln wird MAC Protocol genannt; es wurde in den vorigen Abschnitten ausführlich erläutert. Während sich bei Ethernet alle Adapter gegenüber den vorbeilaufenden Datenpaketen Dritter teilnahmslos zeigen (sofern sie nicht an sie selbst adressiert sind), und während Ethernet-Adapter Datenpakete physikalisch-elektrisch passiv vom Medium abgreifen, agiert jeder Token-Ring-Adapter als aktiver Repeater, der ein jedes im Ring kreisende Paket regeneriert und auf Fehler hin untersucht. Es muss daran erinnert werden, dass die ersten Ringleitungsverteiler rein mechanisch-passiv waren und nichts dergleichen taten! Erkennt ein Token-Ring-Adapter in einem vorüberkommenden Paket irgendeinen Fehler physikalisch-logischer Art, so reagiert er darauf mit zwei Aktionen: •

Der defekte Frame wird mit dem Stempel Error Recognized versehen (E=1).

•

Der gefundene Defekt wird mit einer Fehlermeldung an den Ring Error Monitor publik gemacht.

Um diese Fehlermeldungen schnell zu finden, ist folgender Filter zu setzen: Filter auf (Protokoll-Feld/Parameter) ...

Offset

Wert (hex)

MAC Destination Address

02

C00000.000008

Tab. 13.13: Filter auf Token-Ring Fehlermeldungen an den Ring Error Monitor

Abb. 13.13: Filter auf die MAC-Adresse des Ring Error Monitors

302

Filter auf das MAC-Protokoll

Der Stempel                 '       $             '  

     "      

Hier ist von Bedeutung, dass jeder Token-Ring-Adapter die Adresse seines Vorgängers kennt und diese in jede eigene Fehlermeldung hineinschreibt. Dies führt dazu, dass der Ort eines physikalischen Fehlers sofort erkannt werden kann. Mit anderen Worten: Aus den Meldungen des MAC Protocols ergibt sich die Topologie (die räumliche Anordnung) aller Adapter, und es ergibt sich der Ort des Fehlergeschehens oder wenigstens der Ort der Fehlererkennung. (Es kann sein, dass ein Fehler nicht dort geschieht, wo er von einem Adapter erkannt und gemeldet wird.) Um das alles zu leisten, ist es notwendig, dass die Token-Ring-Adapter sich gegenseitig kennen lernen und sich die MAC-Adresse des jeweiligen Nachbarn in Ringgegenrichtung (also stromaufwärts) merken. Der hierzu ablaufende Ring Poll oder NAUN Process wurde bereits geschildert (siehe 13.4.13). Es wurde bereits auf eine zwar schon ältere, aber immer noch sehr hilfreiche DOS-Software verwiesen, die alle diese Zusammenhänge hervorragend sichtbar macht und die Suche nach Fehlern in der Token-Ring-Physik optimal unterstützt: TokenVision (Triticom). Sie kann keinen der modernen Windows-Analyzer ersetzen, aber sehr wirkungsvoll unterstützen. TokenVision verarbeitet die Frames des MAC Protocols von sich aus in der erforderlichen Weise; auch sind viele Filter von vornherein automatisch gegeben, da sämtliche Fehlermeldungen des MAC Protocols in Echtzeit aufgeschlüsselt und ausgegeben werden. Wer diesen Luxus nicht genießt, weil mit einem vollwertigen LAN-Analysator gearbeitet wird, der noch das Setzen von Filtern abverlangt, muss manuell die Einrichtung der notwendigen Filter auf das MAC Protocol besorgen.

13.6

Filter auf das MAC-Protokoll

13.6.1 Filter sind schön, aber gefährlich! Token-Ring-Analyse lebt davon, das interne Gespräch der Token-Ring-Adapter nachzuvollziehen. Dieses fällt am leichtesten, wenn ein Filter auf das MAC-Protokoll gesetzt wird. Filter auf (Protokoll-Feld/Parameter) ...

Offset

Wert (hex)

Alle Token-Ring MAC Frames

01

0X

Tab. 13.14: Filter auf sämtliche Token-Ring MAC-Frames

Kapitel 13 • Token-Ring

303

Dies geschieht durch folgende Filterdefinition: •

Der Offset (Byte-Position im Paket) für den Filter beträgt »1« (das entspricht dem 2. Byte im Paket).

•

Die Länge der gesuchten Byte-Folge beträgt ebenfalls »1«.

•

Der Wert der gesuchten Byte-Folge wird auf »0X« gesetzt, wobei das »X« für »gleichgültig« steht. Es kommt also nur darauf an, dass die ersten vier Bits dieses Bytes binär sämtlich auf Null stehen (»0000«).

Tatsächlich besagt dieser Filter: Nimm alle Frames, bei denen im Feld »Frame Control« die ersten beiden Bits auf »00« stehen, was » 
     9  ;        ! <=   '' 
 /6 1     Die Protokollparameter, die sich für Filter auf das MAC-Protokoll besonders gut eignen, sind in Tabelle 13.3 (Frame Control) und Tabelle 13.5 (MVID) enthalten. Mit diesen Filtern können Fehler an Adaptern oder Kabeln schnell ausfindig gemacht werden, da die einschlägigen Meldungen der Adapter im Ring eindeutig und zuverlässig sind. So schön übersichtlich es jedoch auch sein mag, über einen MAC-Filter zu arbeiten: Zusammenhänge zwischen Auffälligkeiten auf Token-Ring-Ebene und Auffälligkeiten auf höheren Schichten werden hierdurch nicht sichtbar, sondern unterdrückt, was messtechnisch einen schwerwiegenden Mangel darstellt. Wie ist das zum Beispiel mit dem Adapter, der sich alle paar Sekunden aus dem Ring verabschiedet, um sofort wieder zurückzukehren? Den Anlass für dieses Fehlverhalten muss man auf höheren Schichten suchen – Protokollen also, die durch einen Filter auf das MAC-Protokoll von Token-Ring ausgeblendet werden. Einen solchen Fall hatte der Autor einmal mit einem Router, der sich ca. alle elf bis zwölf Sekunden aus dem Ring verabschiedete, um danach sofort wieder zurückzukommen. Dieses Fehlverhalten wurde ausgelöst durch Ereignisse höherer Protokolle – was nie sichtbar geworden wäre, wenn nur die MAC Frames untersucht worden wären. Andererseits war der Filter auf die MAC Frames geeignet, um schnell den »Sünder« und sein Fehlverhalten nachzuweisen. Danach aber musste wieder »aufgeblendet« werden, um sämtliche Zusammenhänge sehen zu können. Mit der Eingrenzung auf das MAC Protocol mittels Filter muss also sehr bedacht umgegangen werden. Eine Software, die wie vielleicht keine zweite auf Fehlersuche im Physical Layer und MAC-Layer von Token-Ring spezialisiert ist, sind TokenVision und LANdecoder (beide Triticom). Sie laufen zwar »nur« unter DOS, sind aber für solche Aufgaben beide gut geeignet – bis heute.

304

Filter auf das MAC-Protokoll

Jede im Ring liegende Station ist mit ihren MAC-Meldungen zu sehen; auch das möglicherweise erfolgende Ein-/Ausschalten von Adaptern ist sofort sichtbar. Eine in Echtzeit dargestellte Ring-Topologie, in der die Adapter in ihrer tatsächlichen Reihenfolge und mit ihrer jeweiligen Befindlichkeit dargestellt werden, macht Änderungen und Fehler sofort sichtbar. Über Farben können zudem die verschiedenen Adapter ihrem jeweiligen Ringleitungsverteiler zugeordnet werden, was auch Defekte an Ringleitungsverteilern sofort sichtbar macht. Für beide der alten DOS-Programme von Triticom (TokenVision, LANdecoder/tr) gilt, dass ihre Stärke bei Token-Ring darin liegt, dass die Fehlermeldungen des MAC Protocols in Echtzeit dargestellt werden, was bei Windows-Produkten eben nicht mehr der Fall ist, weil dort die Zähler nur noch einmal pro Sekunde angepasst werden. Diese beiden DOS-Programme führen nicht nur die Zähler in Echtzeit, sondern geben auch den Inhalt der Fehlermeldungen aus sowie die Adresse des Absenders und seines Vorgängers: Schneller kann man einen Fehler in der Physik von Token-Ring gar nicht mehr isolieren!

13.6.2 Filter auf Token-Ring Source-Routing Frames Mit einem JA/NEIN-Wahlschalter zum Filter auf Source-Routing (SR) Frames lässt sich auf simple Weise bestimmen, ob man nur Verkehr zwischen Adaptern im lokalen Ring sehen will (SR=NEIN), oder ob auch von außen kommender bzw. nach außen führender Verkehr eingelesen werden soll, der über Source Route Bridges läuft (SR=JA). Source-Routing wird hauptsächlich in Token-Ring-Umgebungen verwendet, die (noch) von SNA (IBM) geprägt sind. Da die meisten Token-Ring Bridges inzwischen auch den bei Ethernet gebräuchlichen Transparent Mode unterstützen, haben viele Unternehmen das Source-Routing bei Token-Ring abgeschafft. Für diese Abschaffung spricht, dass es zu massiven Fehlern kommen kann, wenn auf einem Rechner Applikationen, die SR verwenden, gleichzeitig betrieben werden mit solchen, die es nicht verwenden bzw. gar nicht verwenden können, weil die Programmierer diesen Fall nicht vorhersahen. Wenn eine klassische Client-Server-Applikation, die z.B. auf IP und Ethernet programmiert wurde, auf Token-Ring eingesetzt wird, wenn zugleich eine andere Applikation den Token-Ring-Treiber ständig anweist, mit Source-Routing zu arbeiten, so kann der Datenfluss der Client-Server-Applikation massiv in Mitleidenschaft gezogen werden. Zuletzt besteht die Gefahr, dass Ethernet-Applikationen traditionell reichlich mit Broadcasts arbeiten – was beim Konflikt zweier Applikationen, die über die Verwendung von SR uneins sind, zu erheblichen Broadcast-Stürmen führen kann. Bei einem Kunden konnte dieser Effekt wie folgt beobachtet werden: Ein einziger LAN-Broadcast wurde jeweils (seitens der Applikation wider Willen) als sog. All-Routes-Broadcast per SR verschickt, was bei der starken Vermaschung der einzelnen Ringe über SR-Brücken dazu führte, dass die Broadcasts teilweise um

Kapitel 13 • Token-Ring

305

den Faktor 30 vervielfältigt wurden: Aus 1 mach 30! Die daraus resultierenden Broadcast-Stürme brachten regelmäßig die Server zum Absturz, weil die Interrupt-Auslösungen in der PC-Architektur nicht mehr beherrschbar waren. Token-Ring-Analyse muss also die Verwendung von Source-Routing daraufhin überprüfen, ob sie seitens der Applikationen korrekt stattfindet, wobei auf die Broadcasts gesondert geachtet wird. Filter auf Source-Routing Frames werden in aller Regel nicht manuell gesetzt, sondern vom Analyzer angeboten, da nur auf ein einzelnes Bit gefiltert wird, nämlich das erste Bit in der MAC Source Address eines Frames. Dieses Bit ist der sog. Routing Information Indicator (RII); es zeigt an, ob im Frame ein Routing Information Field (RIF) enthalten ist. Normalerweise ist dies nicht der Fall, da auf die MAC Source Address meistens sofort der LLC Header folgt. Wenn ein RIF vorhanden ist (es trägt sämtliche Information für das Source-Routing in sich), so liegt es zwischen der MAC Source Address und dem LLC Header. Dies wird dadurch angezeigt, dass das erste und dafür reservierte Bit in der MAC Source Address von »0« auf »1« gesetzt wird und somit den Routing Information Indicator (RII) darstellt. Dieses Bit, ist es denn auf »1« gesetzt, ist nicht Teil der MAC-Adresse. Im HexFenster des Analyzers erscheint dann manchmal z.B. für das erste Byte der MACAdresse der Wert 0x90, während die MAC-Adresse in der Decoder-Darstellung mit 0x10 beginnt:

Abb. 13.14: Unterschiedliche Darstellung des ersten Bytes einer MAC Source Address bei gesetztem RII-(Routing Information Indicator)Bit

Ein manuelles Setzen eines Filters auf SR-Frames wäre eine unerfreuliche Bastelei; hier ist man auf die Unterstützung des Analyzers angewiesen.

306

13.7

Die logischen Adressen von Token-Ring

Die logischen Adressen von Token-Ring

13.7.1 Das Prinzip der logischen Adressen IBM hat es bei der Entwicklung von Token-Ring praktisch zur Regel gemacht, dass nicht die werksseitig eingebrannten MAC-Adressen verwendet werden (Universally Administered Address, UAA gemäß IEEE), sondern logische Adressen (Locally Administered Address, LAA), in denen sich die Funktion des dahinter arbeitenden Geräts widerspiegelt. Hierbei sind die vom MAC Protocol verwendeten logischen Adressen zwingend vorgegeben, während alle weiteren lediglich eine Empfehlung von IBM darstellen. So kann aus einer logischen Adresse hervorgehen, dass es sich z.B. um den zweiten Adapter einer AS/400 handelt oder um den ersten Adapter einer Steuereinheit. Um den Zugang zum SNA-Host über zwei Gateways redundant auslegen zu können, war von Anfang an klar, dass es Token-Ring-Terminals möglich sein musste, wahlweise über einen von zwei Ringen an eines der beiden Gateways heranzukommen. Und da in der Terminal-Emulation die MAC-Adresse des GatewayAdapters fest eingestellt wird, müssen beide Gateway-Adapter die identische MAC-Adresse aufweisen; da dies aber im selben Ring unmöglich ist, müssen sie aus diesem Grund in zwei verschiedenen Ringen liegen. Wenn aber unterschiedliche Ringe existieren, müssen dieselben über Nummern adressierbar sein, damit die Pakete den »richtigen« Weg zum »richtigen« der beiden Gateways nehmen. Hierzu nahm IBM zu Beginn der Entwicklung bei logischen Adressen folgende Aufteilung vor: Die ersten vier Bits einer Adresse sind nicht eigentlich Bestandteil der Adresse. Während die Bits drei und vier bis heute nicht verwendet werden (sollen), kennzeichnet Bit Eins mit »0«, dass es sich bei der Zieladresse um eine Inidividualadresse handelt, während Bit Eins mit »1« als Empfängeradresse eine Multicastbzw. Broadcast-Adresse anzeigt (I/G-Bit: Individual or Group). Das Bit Zwei kennzeichnet, ob es sich um eine originale Werksadresse handelt (»0«) oder um eine administrativ vergebene logische Adresse (»1«) (U/L-Bit: Universally/ Locally Administered Address, UAA/LAA). Da bei Token-Ring (im Gegensatz zu Ethernet) das Most Significant Bit (MSB) zuerst dargestellt wird, erscheint eine logische Individualadresse in den ersten Bits mit der Folge »0100« hexadezimal als 0x40, während eine logische Multicast-Adresse mit »1100« als 0xC0 erscheint. Eine standardgemäße Gruppenadresse (UAA) erscheint mit »1000« als 0x80. Da die Bits fünf bis sechzehn – also die verbleibenden zwölf Bits der ersten zwei Bytes einer logischen Adresse – immer auf »Null« stehen, ergeben sich bei logischen Adressen die Präfixe 0x4000 und 0xC000. (Bei Ethernet erscheinen diese Adressen in LSB-Mode als 0x02 und 0x03.)

Kapitel 13 • Token-Ring

307

Abb. 13.15: Logische Token-Ring MAC Destination Address = LAA

Die zwölf unbenutzten Bits waren für eine frühe, erste Version des Token-Ring Bridgings gedacht: Hier sollte die Adresse von Ziel-Ring(en) Platz finden. Die spätere Version des Source-Route Bridgings machte diese zwölf Bits sodann überflüssig, weil nunmehr bei gewachsenem Platzbedarf die Routing-Angaben ins sog. Routing Information Field (RIF) zwischen MAC Source Address und LLC gelegt werden. In den verbleibenden vier Bytes steckt dann die eigentliche, logische Adresse der Adapter.

13.7.2 Fest vergebene logische Adressen Folgende logische Funktionsadressen sind fest vergeben: MAC Functional Address

Destination Station

C0 00 00 00 00 01

Active Monitor

C0 00 00 00 00 02

Ring Parameter Server

C0 00 00 00 00 04

Network Server Heartbeat

C0 00 00 00 00 08

Ring Error Monitor

C0 00 00 00 00 10

Configuration Report Server

C0 00 00 00 00 20

Synchronous Bandwidth Manager

C0 00 00 00 00 40

Locate Directory Server

C0 00 00 00 00 80

NetBIOS

C0 00 00 00 01 00

Bridge

C0 00 00 00 02 00

IMPL Server

C0 00 00 00 04 00

Ring Authorization Server

Tab. 13.15: MAC Funktionsadressen von Token-Ring

308

Die logischen Adressen von Token-Ring

MAC Functional Address

Destination Station

C0 00 00 00 08 00

LAN Gateway

C0 00 00 00 10 00

Ring Wiring Concentrator

C0 00 00 00 20 00

LAN Manager

C0 00 40 00 00 00

AppleTalk Multicast (TLAP)

C0 00 FF FF FF FF

Local Ring Broadcast

FF FF FF FF FF FF

LAN Broadcast (All Rings)

Tab. 13.15: MAC Funktionsadressen von Token-Ring (Forts.)

Bei diesen Adressen erscheint vorne immer in den ersten zwei Bytes die Folge 0xC000 für »Group Address/Locally Administered Address« (GA/LAA), die von den sendenden Adaptern immer automatisch gesetzt wird. Warum sind Funktionsadressen immer Gruppenadressen? Nun: Der Absender weiß nie, wie viele Adapter die angesprochene Funktion gerade ausüben. So ist es z.B. bei Fehlermeldungen völlig offen, ob es überhaupt einen          % -    

13.7.3 Funktionsadressen am Beispiel des RPS Was sind Funktionsadressen? Dies soll an einem Beispiel verdeutlicht werden: Ein neuer Adapter kommt in den Ring. Er hat seinen Selbsttest und Kabeltest hinter sich gebracht, hat das Relais am Ringleitungsverteiler geöffnet, hat die vorhandene Frequenz als seine eigene identifiziert (oder hat sich auf die verwendete Frequenz eingestellt), hat am Ring-Poll-Prozess teilgenommen (NAUN Process) und hat seine neue Nachbarschaft gemeldet (NAUN Change). Jetzt fehlt ihm nur noch eines: Er muss sich vergewissern, dass er mit den richtigen Betriebsparametern arbeitet – insbesondere, was die Umlaufzeit des Tokens anbetrifft. (Das war früher einmal sehr wichtig, als die Ringe die vorgesehene Maximalausdehnung überschreiten konnten; dies ist heute praktisch nirgendwo mehr der Fall.) Der neue Adapter sucht also nach einem Ring Parameter Server (RPS). Nur – wo mag der stecken? Und – welche MAC-Adresse mag der wohl haben? Da der neue Adapter das alles nicht weiß (und auch gar nicht wissen soll), ruft er einfach mit einem Ring-Multicast in den Ring hinein: »Hallo, gibt es hier einen RPS?« Und dieser Rundruf wird an die Funktionsadresse des RPS gerichtet: MAC = C000.00000002 Ring Parameter Server

Alle Adapter, auf denen in der Software ein RPS arbeitet, nehmen diesen Frame auf (sie erkennen ihn also als an sich selber adressiert) und reichen ihn an den RPS-Prozess weiter, der seinerseits dem neuen Adapter antwortet und ihm die aktuellen Betriebsparameter mitteilt.

Kapitel 13 • Token-Ring

309

Dies könnten sein: Eine vom Standard abweichende Token Rotation Time, eine neue logische Adapteradresse (LAA), ein neuer Zeitwert für Fehlermeldungen (für gewöhnlich erfolgen Fehlermeldungen genau zwei Sekunden nach Eintritt des gemeldeten Ereignisses). Heutzutage gibt es entweder erst gar keinen RPS mehr, oder er meldet gerade mal die aktuelle Ringnummer (die der Adapter auch anders und damit sowieso erfahren hätte). Der neue Adapter erhält die RPS-Meldung und lernt dadurch auch dessen tatsächliche MAC-Adresse; die erforderliche Quittung für den Erhalt der Parametermitteilung schickt der neue Adapter sodann nicht mehr an die Funktionsadresse (die für die Quittung eine zu ungenaue Gruppenadresse wäre!), sondern an die tatsächliche MAC-Adresse des RPS. Auch den Funktionsadressen ist eigen, dass sie im Prinzip so aufgebaut sind, dass die ersten Bytes auf 0xC000 gestellt sind, während erst die letzten vier Bytes die eigentliche Adresse enthalten.

13.8

Token Ring Source-Routing Warum aber nun haben nach den ersten vier Bits die nachfolgenden zwölf Bits keine weitere Verwendung?

13.8.1 »Ring Number« Zunächst einmal wird auf die Ausführungen im vorigen Abschnitt 13.7.1 verwiesen, der bereits den Aufbau der MAC-Adressen beschrieben hat. Ende der 70er Jahre ging IBM davon aus, dass in die reservierten 12 Bits einer logischen MAC-Adresse die Ringnummer des Ziel-Ringes eingetragen würde: Ein Ring mit Client-Adaptern sollte über je eine Brücke Zugang haben zu den beiden Ringen, in denen je eines der beiden SNA-Gateways angesiedelt war. Die Ringvorwahl sollte darüber bestimmen, über welches der beiden Gateways gearbeitet werden sollte. Diese Verfahrensweise hatte den unannehmbaren Nachteil, dass nur über eine einzige Brücke gearbeitet werden konnte – oder aber man kam in die Situation, dass sich die Token-Ring-Brücken wie Layer-3-Router ausgedehnte Routing-Tabellen hätten zusenden müssen, um sich über die verfügbaren Verkehrswege zu informieren. Beides war für IBM und für die Kundschaft letztlich nicht (mehr) akzeptabel. Daher wurde das Prinzip des sog. Source-Routings eingeführt: Ein Token-RingFrame kann bis zu sieben Brücken überqueren, wobei der Absender (der SNATeilnehmer also) exakt vorgibt, über welche Brücken und Ringe der Frame zu laufen hat. »Source-Routing« lässt sich demgemäß etwa mit »Routing-Vorgabe des Absenders« übersetzen.

310

Token Ring Source-Routing

Da eine dergestalt ausgedehnte Adressierung niemals vorne in den sechs Bytes der Empfänger-MAC-Adresse unterzubringen war, kam das RIF (Routing Information Field) hinter die Absender-MAC-Adresse (und somit vor LLC).

13.8.2 Das Routing Information Field (RIF)

Abb. 13.16: Der Aufbau des Routing Information Field (RIF)

Die verschiedenen Parameter bedeuten: RIF/Routing Type BBB-Bits

Bedeutung

BBB = 0??

Non-Broadcast Zeigt an, dass in den Feldern        -) $%# 

BBB = 10?

ARB = All-Routes Broadcast Alle verfügbaren Verbindungen ( 
"  )-  

    )    "

) 

 -) $%#   -)    5" !  )  ""  6 "    " "    )   """ &  -) ,!  

Hierdurch wird der Frame auf dem Weg zum Empfänger vervielfältigt. Dieser beantwortet jeden bei ihm ankommenden ARB über den Weg, den dieser genommen hat: Die Wegebeschreibung bleibt, nur das Direction Bit wird umgesetzt. Tab. 13.16: RIF Parameter – Routing Type

Kapitel 13 • Token-Ring

311

BBB-Bits

Bedeutung

BBB = 11?

SRB = Single-Route Broadcast Der Frame soll nach dem  7    &        5  6"  )  8  "    - 6, )   9        !  )   &,  

 6,

  

Das SRB-Verfahren sollte auf Brücken eingesetzt werden, die im sog. Transparent Mode arbeiten und die damit gewissermaßen kompatibel zu Ethernet und den dort gebräuchlichen Protokollen sind. Tab. 13.16: RIF Parameter – Routing Type

RIF/Length Dieser Parameter gibt die Länge des Routing Information Field (RIF) insgesamt an, damit alle lesenden Adapter dieses Feld überhaupt einwandfrei aus dem Gesamt-Frame heraus trennen können. Die maximale Länge des Feldes beträgt 18 Byte: [2 Bytes Routing Control] + [{2 Bytes Route Designator} * 8]

Wird ein Frame per ARB oder SRB gesendet, beträgt der Wert des Length-Parameters »2« (für die beiden Bytes des Feldes Routing Control). Jede Bridge, die den Frame auf einen weiteren Ring vermittelt, erhöht den Length-Wert um 4 (Source Segment Number + Next Ring Segment Number). Jede weitere Bridge erhöht den Wert um 2 (Next Ring Segment Number). Da nur acht Felder für die Route Designator zur Verfügung stehen, kann ein Frame höchstens sieben Bridges auf seinem Weg zum Empfänger überqueren; insgesamt kann der Frame somit über acht Ringe laufen. p

Tipp Eselsbrücke: »Über sieben Brücken sollst du geh’n...« Non-Broadcast Frames enthalten bereits die gesamte Pfadangabe; ihre Längenangabe bleibt daher auch beim Weg über mehrere Bridges unverändert. Enthält das Routing Information Field (RIF) weniger als 2 Byte oder mehr als 18 Bytes oder eine ungerade Anzahl an Byte, wird der Frame nicht von Bridges vermittelt (da ungültig). RIF/Direction Das Richtungs-Bit wird benötigt, damit die Reihenfolge klar ist, in der die Route Designators gelesen werden müssen:

312

Token Ring Source-Routing

Direction Bit

Richtung

Sender <> Empfänger

D=0

Vorwärts

Auf dem Weg vom Sender zum Empfänger

D=1

Rückwärts

Auf dem Weg vom Empfänger zum Sender

Tab. 13.17: RIF Parameter – Direction Bit

RIF/Largest Frame Size Der Wert dieser Bits gibt die Maximalgröße des Datenfeldes an, das zwischen zwei Token-Ring-Stationen über einen bestimmen Pfad ( 1       "

Eine Station, die einen Broadcast-Frame verschickt, setzt die 3 Bit der Largest Frame Size (als »FFF« bezeichnet) auf FFF=111 und damit auf den höchsten Wert, womit gekennzeichnet wird, dass von einer Route ohne jegliche Längenbeschränkung ausgegangen wird. Dieser Wert wird von allen Bridges überprüft, die diesen Frame bearbeiten. Ist der Wert zu hoch bezüglich der Route, über welche die Bridge vermitteln soll bzw. kann, so passt die Bridge den FFF-Wert der maximal unterstützten Paketgröße der aktuellen Route an. Achtung! Bei Fehlern, die IP-Verbindungen betreffen, sind die kleinen »PING«Tests wenig wertvoll, solange diese (wie allgemein üblich) nur mit Paketen von 64 Byte Größe gesendet werden – mögliche Fehler, die aus der Beschränkung der Largest Frame Size herrühren, können hiermit nicht erfasst werden! p

Warnung Vorsicht bei »PING«-Tests!

FFF Bits

Max. Länge des Daten-Feldes

000

516

001

1.500

010

2.052

011

4.472

100

8.144

101

11.407

110

17.800

111

Unbeschränkte Länge; Ausgangswert bei All-Route-Broadcasts

Tab. 13.18: RIF-Paramenter – Largest Frame Size

Die Größenwerte nehmen Rücksicht auf andere Topologien, die zum Transit genutzt werden könnten, so z.B. der Wert »1.500«, der die maximale Datengröße von Ethernet beschreibt.

Kapitel 13 • Token-Ring

313

Andererseits werden heute selten Pakete über Token-Ring gesendet, die größer sind als 4.096 Byte; dies hat wiederum mit Kompatibilität zu anderen Topologien zu tun, hauptsächlich FDDI (LAN) und Frame Relay (WAN), die beide ANSIStandards sind und Pakete bis 4.500 Bytes unterstützen. Wo Token-Ring Source-Routing verwendet wird, und gleichzeitig Transitstrecken unterschiedlichster Topologien genutzt werden, können bis heute Fehler mit den Längenbeschränkungen auftauchen. Tipp Auf ICMP-Meldungen achten, die von Bridge/Routern kommen. Router, die zugleich als Token-Ring-Brücken arbeiten, könnten ggf. auf Layer 3 aus demselben Grunde IP-Pakete verwerfen, weil diese zwar hätten fragmentiert werden müssen (können), aber der IP-Absender dieses ausdrücklich mittels Markierung im IP-Header verboten hat (»Don’t Fragment«); solche Ereignisse werden mittels ICMP an den Absender gemeldet. Dieses kann man sich manchmal zunutze machen, wenn es Fehler auf Layer 2 im Source-Routing gibt, da Token-Ring-Bridges keine Fehlermeldungen zurückgeben, wenn sie Pakete nicht weitervermitteln können. RIF/Route Designator Bridges lesen das Feld            >   

  •

... von Ring Number mit der Nummer des angeschlossenen Ringes;

•

... von Bridge Number mit ihrer eigenen Bridge-Kennung.

Bei Broadcast-Frames fügt die Bridge einen weiteren Route Designator hinzu, sofern noch keine acht Route Designator im Frame erreicht sind. Bei massiven Störungen muss nach doppelten Ringnummern bzw. doppelten Bridge-Nummern gesucht werden. Da Ringnummern wie auch Brückennummern durch die Konfiguration der Brükken vergeben werden (und nur dort), ist die Nachprüfung am leichtesten, wenn man Zugriff auf die Einstellungen der Brücken hat. Ansonsten muss in allen Ringen gemessen und verglichen werden.

13.8.3 Wegewahl: ARB, SRB, Explorer Frame Die Wahl für einen der zum Ziel führenden Wege erfolgt über einen ExplorerFrame (»Kundschafter«), der als Source-Route Broadcast gesendet wird. Hierbei gibt es zwei Varianten: •

ARB = All-Routes Broadcast

•

SRB = Single-Route Broadcast

314

Token Ring Source-Routing

Beim ARB schickt der Absender einen Explorer los mit der Anweisung im RIF (Routing Information Field) an alle Brücken, diesen Frame in sämtliche Ringe zu verteilen. Dies führt je nach Vermaschung der Ringe untereinander dazu, dass der Explorer-ARB entsprechend vervielfältigt beim Empfänger ankommt. Da jede Brücke ihre Brücken- und Ringnummer im Explorer-ARB einträgt, ist dem Empfänger der Weg bekannt, über den der Explorer-Frame zu ihm kam. Der Absender übernimmt das bei ihm eintreffende RIF, setzt nur das Richtungs-Bit von »vorwärts« auf »rückwärts« um und schickt die Antwort zurück an den Absender (den Initiator des Verbindungsaufbaus). Dieser erhält auf diese Weise ggf. mehrere Antworten zurück (je nach Vermaschung und Zahl der Brücken) und kann sich nunmehr für genau den Weg entscheiden, über den zuerst eine Antwort zurückkam. Will der Absender statistisch genau arbeiten und den wirklich schnellsten Weg herausfinden, kann er mehrere Explorer-Frames losschicken und zwischen den Antwort-Frames bzw. ihrer RIFs das arithmetische Mittel bilden. Nach drei oder fünf Versuchen müsste klar sein, welcher Weg zuverlässig der schnellste ist. Die Entscheidung, wie viele Explorer Frames geschickt werden, wird vom Programmierer der Applikation getroffen, in aller Regel SNA-Terminal-Emulationen. Beim SRB geht der Explorer Frame nur über genau einen Weg zum Ziel, um dann aber von dort über alle Wege beantwortet zu werden. SRBs sind daher statistisch nur halb so aussagefähig über den Durchsatz der Transitringe wie ARBs.

13.8.4 Mehrere Wege Es ist bewußt gewollt und im Source-Routing angelegt, dass zwischen A und B (zwischen SNA-Terminal und SNA-Host) verschiedene Routen vorhanden sind. Ist jedoch erst einmal eine Session über einen der verfügbaren Wege aufgebaut, muss die gewählte Route für den gesamten Zeitraum der Session beibehalten werden. Fällt die gewählte Route aus, stirbt auch die Session; sie muss über einen anderen Weg (via ARB, SRB) erneut aufgebaut werden. Dies ist meistens jedoch bei SNA-Sessions unbedenklich, da der Host ja die Daten unabhängig vom Status der Session hält. Um alle verfügbaren Routen via Token-Ring Source-Routing Bridges nachzuweisen, lese man einen Tag lang den Token-Ring-Verkehr via Analyzer mit, um später die Trace-Daten auszuwerten, beispielsweise mittels LANreport (Synapse). Heraus kommt eine genaue Verkehrstabelle, in der nachgewiesen wird, wie viele Frames von A nach B laufen über Transit-Ring C oder D.

13.8.5 Konkurrierende Routing-Angaben Zu einem der schlimmsten Token-Ring-Fehler kann sich das Source-Routing entwickeln, wenn es unter IP bzw. IPX verwendet wird sowie unter Applikationen, die den Token-Ring-Treiber nicht angemessen ansteuern.

Kapitel 13 • Token-Ring

315

Dies will erläutert sein: Bei Verwendung der ursprünglich auf Ethernet programmierten Routing-Protokolle wie IP oder IPX (Netzwerk-Schicht, Layer 3) adressiert der Absender seine Daten an die MAC-Adresse des zuständigen Routers; dieser reicht die Pakete in die gewünschte Richtung weiter, tut dies aber nach eigenen, für den Absender nicht ersichtlichen Regeln. Eröffnet der Absender die Client-Server-Session nur via ARB/SRB, und verfügt der Router zugleich über ein Token-Ring Source-Routing-Modul (Bridge/Router, auch Brouter genannt), so schreibt der Absender in der Folge sowohl die IP-Zieladresse ins Datenpaket sowie auch den gesamten Token-Ring Source-RoutingWeg (RIF). Dies kann dazu führen, dass das Paket zum Empfänger laut RIF einen anderen Weg nehmen müsste, als dies der Router gemäß seinen IP-Routing-Tabellen entscheiden würde. Normal wäre nun, dass die Kommunikation korrekt und konfliktfrei verläuft. Es wurden aber bereits vom Verfasser mehrfach Fälle beobachtet, in denen Router mit doppelten Routing-Angaben nicht einwandfrei arbeiteten – mit der Folge eines gewaltigen Durcheinanders. Aber auch dann, wenn dieser Fehler nicht auftritt, bleibt eine unangenehme Erscheinung weiterhin bestehen: das ungleiche Broadcast-Verhalten bzw. die durch die Vermaschung der Ringe unabwendbare Vervielfältigung aller Broadcasts. Überall dort, wo Client-PCs sowohl Client-Server-Sessions z.B. mit NetWareoder WinNT-Servern haben, aber zugleich auch SNA-Terminal-Emulation (3270 SNA) betreiben, kann der Konflikt bestehen, dass für die 3270-Emulation das Token-Ring Source-Routing Treiber-Modul geladen werden muss. Ist das der Fall, wird der Adaptertreiber seitens der 3270-Emulation laufend angewiesen, per Source-Routing zu arbeiten und vor allem ggf. mit ARBs – was die Vervielfältigung bewirkt (anders als SRBs). Die Client-Server-Applikationen aber setzen für ihre eigenen Übertragungen den Treiber oft nicht zurück auf den für sie nötigen Status ohne Source-Routing (weil die Programmierer daran schlicht nicht dachten), und schon wird das LAN überflutet mit Broadcasts. Wo auf die 3270-Emulation nicht verzichtet werden kann, bestehen nur folgende Lösungen: •

Der Hersteller des Token-Ring-Adapters hat dokumentiert, wie man den Treiber zwingen kann, nur mit SRBs zu arbeiten. Dies führt regelmäßig zu einem Eintrag in der Windows-Registry.

•

Die Windows-Registry muss so eingestellt werden, dass bei IP-ARP nur mit SRBs oder ganz ohne Source-Routing gearbeitet wird:

316

Token Ring Access Priority

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters\ArpAlwaysSourceRoute HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters\ArpTRSingleRoute Listing 13.1: WinNT Registry-Einträge zu Token-Ring Source-Routing

•

Wirkt das nicht, besteht die letzte Lösung darin, das SNA-Gateway (das bis jetzt über LLC/Layer 2 angesprochen wird) durch ein IP-Gateway zu ersetzen. Hierdurch wird das Token-Ring Source-Routing abgeschafft und durch IPRouting ersetzt. Jetzt können entweder sämtliche Treiber auf SRB umgestellt werden, oder die Source-Route Bridges werden aus dem Netz genommen und durch Router ersetzt.

Grundsätzlich zeigt die Erfahrung, dass Client-Server-Applikationen oft seitens der Hersteller nur auf Ethernet getestet wurden; der Einsatz auf Token-Ring führt dann oft zu unvorhergesehenen Fehlern.

13.9

Token Ring Access Priority Ein anderer Fallstrick ist im Umfeld von Source-Route Bridging verborgen, der mit der Token-Ring Access-Priority zu tun hat.

13.9.1 Zugriffsprioritäten Es ist eine Mär, dass alle Adapter im Ring gleich oft mittels Token das Senderecht erhielten. Ein gleichmäßiges Zugriffsrecht wäre auch gar nicht wünschenswert. Man stelle sich vor: Zwanzig Client-PCs schicken reihum jeweils einen Datenrequest an den Server. Zu diesem kommt jetzt das Token, und der Server dürfte nur genau einen der zwanzig Requests bedienen! Das wäre höchst hinderlich. Dem Server muss Gelegenheit gegeben werden, so oft zu senden, bis er auf alle Client-Requests geantwortet bzw. seinen Ausgangspuffer leer gesendet hat. Entsprechend oft muss das Token für den Server verfügbar sein – und zwar außerhalb des üblichen Kreislaufs. Hierzu wurde einigen Geräteklassen das Recht verliehen, sich das Token bei Bedarf zu greifen und aus seinem Kreislauf zu reißen (quasi per »Interrupt«, da ja der Token-Kreislauf »unterbrochen« wird), um dann genau ein Paket zu senden und um sodann das Token dorthin zurückzugeben, von wo es »geliehen« wurde. Das funktioniert wie folgt: Unser Server – wir bleiben im Beispiel – empfängt einen Client-Request. Er kopiert sich das Paket in seinen Eingangsspeicher, quittiert den Empfang und reicht den Frame weiter. Sobald der Server den Reply (die Antwort) in seinem Ausgangspuffer hat, greift er sich den nächsten, beliebigen

Kapitel 13 • Token-Ring

317

Frame, der vorbeikommt, und stempelt vorne im ersten Oktett namens Access Control eine Token-Reservierung hinein. Dies tut der Server mit seiner ihm eigenen Access Priotity, die bei ihm (wie bei allen Servern) den Wert »3« hat. Der Absender des so benutzten Frames erkennt die Token-Reservierung und macht nun Folgendes: Er nimmt – wie vorgesehen – seinen Frame vom Ring, gibt auch wie üblich ein Token aus, aber eben kein gewöhnliches Token, sondern ein reserviertes Prioritäts-Token. Die Access Priority des Antragstellers (also unseres Servers) wird aus den sog. Reservation Bits übertragen in die Priority Bits. Jetzt darf sich dieses Token nur noch greifen, wer eine gleiche oder größere Access Priority hat als der in den Priority Bits des Tokens hinterlegte Wert (und wer zudem eine solche Reservierung vorgenommen hat).

Abb. 13.17: Token-Ring – Access Control – Access Priority

Selbst unterstellt, dass alle weiteren Client-Adapter im Ring senden wollten, so dürften sie sich dieses reservierte Prioritäts-Token doch nicht greifen – denn mit ihrer jeweiligen Access Priority von genau »Null« sind sie nicht berechtigt, sich das Prioritäts-Token zu greifen, das den Prioritäts-Wert »3« trägt. Dieses reservierte Prioritäts-Token erreicht nun unseren Server. Er weiß: Ich brauche ein Token, ich habe eins beantragt, dieses hier stimmt mit meiner Access Priority überein, also wird das hier wohl meins sein. Er sendet seinen Reply an den Client, dessen Request er zu Beginn erhalten hatte, und nimmt nach Rücklauf des Reply-Frames diesen wieder vom Ring und gibt das Prioritäts-Token weiter – mit dem darin enthaltenen Prioritäts-Wert von »3«. Hierdurch ist garantiert, dass alle verbleibenden Client-Adapter im Ring das Token nicht anrühren – bis es wieder bei genau jenem Adapter anlangt, der das Prioritäts-Token aufgrund der erkannten Reservierung generiert hatte. Dieser Adapter muss auf die Rückkehr des Prioritäts-Token warten, bis es an ihn zurück gegeben wird (wie jetzt geschehen). Er nimmt es sogleich von der Leitung und reicht jetzt ein »normales« Token mit der Priorität »Null« weiter:

318

Token Ring Access Priority

Der normale Umlauf des Token wird jetzt – nach der Unterbrechung durch den Server – weiter fortgesetzt. Theoretisch könnte so auf jeden Client-Request (durchgeführt mittels NormalToken) ein Server-Reply kommen (durchgeführt mittels Reservierungs-Token). Daraus ergibt sich theoretisch (erwünscht und im Standard angelegt), dass es ein Server in der Verwendung des Token auf die Summe aller Client-Requests bzw. aller anfallenden Server-Replies bringt. In gewisser Weise ist damit das Polling des alten FEP, das dieser gegenüber seinen Terminals zeigt(e), exakt nachgebildet.

13.9.2 Schieflage: Router und Server vs. Brücken Um SNA-Dialoge, die über Source-Route Bridges laufen, gegenüber den weniger zeitempfindlichen Client-Server-Dialogen zu schützen, die zudem sehr stoßartig und Ressourcen fressend ablaufen können, hat IBM folgende Skala für die Access Priority festgelegt: Geräteklasse

Zugriffspriorität/Access Priority

Client-PCs/Terminals

0–2

Server, Router

3

Source-Route Bridges

4

MAC Frames

7

Tab. 13.19: Token-Ring Access Priority

Hat sich nun historisch eine Anordnung entwickelt, dergestalt, dass einige ClientRinge via  (         ')(*(   !"  3        %   (    $

Alle diejenigen Anwender, die via Source-Route Bridge ins Backbone gelangen, freuen sich allgemein über kurze Antwortzeiten, weil ihnen die Brücken den Zugriff auf den Backbone-Ring mittels Priorität=4 verschaffen. Alle diejenigen Anwender, die über Layer-3-Router ins Backbone gelangen, klagen über die teilweise extrem langen Ladezeiten, weil sie leider nur mit Priorität=3 ins Backbone gelangen! Tipp Im Backbone-Ring sind nicht alle gleich! Im Einzelnen bedeutet das: Die Source-Route Bridges verleihen allen Anwendern, die über sie arbeiten, die Access Priority auf das Backbone-Token mit Wert »4« – während alle anderen, die mit einer Access Priority von »3« via Router arbeiten, von diesem Wert »3« im Falle hoher Backbone-Auslastung praktisch

Kapitel 13 • Token-Ring

319

nichts haben, da die Source-Route Bridges ggf. vorhandene Token-Reservierungen der Server (Wert »3«) ausnahmslos bei Bedarf mit ihrer eigenen Reservierung (Wert »4«) überschreiben. Es muss also genau geprüft werden, wo Bridging und wo Routing stattfindet bzw. stattfinden soll, um für alle Anwender einen gerechten Datendurchsatz zu gewährleisten.

13.10 Ferndiagnose via RMON und CMOL Es haben sich historisch zwei verschiedene Standards zur Fernüberwachung im Token-Ring etabliert.

13.10.1 RMON Der heute gängige Standard zur LAN-Fernüberwachung ist RMON (Remote Monitoring): •

RMON-I für Statistik

•

RMON-II für Analyse

Die hierfür notwendigen RMON-Agenten sind jedoch in den älteren Token-RingKomponenten nicht enthalten; in den elektromechanischen Ringleitungsverteilern schon gar nicht. Um hier Nachrüstung zu betreiben, bedarf es •

entweder des Einsatzes neuer, elektronischer Ringleitungsverteiler oder TokenSwitches, die in aller Regel wenigstens RMON-I beinhalten,

•

oder des Zuschaltens externer RMON-Agenten, sog. RMON-Probes.

Es sollte bei der Neuanschaffung aktiver Komponenten darauf geachtet werden, dass sie Agenten für SNMP, RMON-I und RMON-II enthalten.

13.10.2 CMOL und OS/2 LAN Network Manager IBM hat Anfang der 90er Jahre unter OS/2 eine Token-Ring Management Suite herausgebracht mit dem Namen OS/2 LAN Network Manager. In dieser Token-Ring Management Suite setzt IBM einen internationalen und im Grunde für alle UNO-Mitgliedsstaaten juristisch verbindlichen ISO-Standard um: CMOL =

CMIP over LLC

=

Common Management Information Protocol over Logical Link Control

320

Token-Ring, LLC-SNAP und Ethernet

Über eine zentrale, unter OS/2 laufende Management-Station kann auf alle

 %%     &      "      30(?43(    /1 "    30(?43( '"    !  -   ." 3       %           %   

 (   

 (

   

Wer immer den OS/2 LAN Network Manager hat, möge sich glücklich schätzen! Die Möglichkeiten der Inventarisierung, des Monitoring und der Fehleranalyse sind vielfältig und immer hilfreich. Zwar kann ein Analyzer dadurch nicht ersetzt werden – aber man hat von einer zentralen Konsole aus Zugriff auf alle Adapter. Der OS/2 LAN Network Manager jedoch dürfte seine Zukunft bereits hinter sich haben.

13.11 Token-Ring, LLC-SNAP und Ethernet Im Kapitel über Ethernet-Analyse schilderten wir die verschiedenen, unter Ethernet existierenden Frame-Typen. Es sei hier darauf verwiesen, dass bis auf den historisch ältesten – Ethernet II – alle im Zuge der IEEE-Standardisierung entstanden, als es darum ging, die ursprünglich auf Ethernet programmierten Protokolle wie IP und IPX auch über Token-Ring-LANs laufen zu lassen. Hierzu wurde das bei Token-Ring damals vorhandene SDLC (Synchronous DataLink Control) leicht modifiziert und als LLC (Logical Link Control) auch in die Ethernet-Welt hineingetragen – die es bis heute entweder gar nicht oder doch nur zurückhaltend verwendet. Durch einen Planungsfehler beim IEEE ersetzte man das 16 Bit lange EtherTypeFeld durch einen nur noch 8 Bit langen LLC-SAP (wovon wiederum 2 Bit vorab reserviert waren). Das konnte nicht gut gehen. Mit der Entwicklung weiterer Protokolle wie ARP im Zuge der TCP/IP-Entwicklung an der Berkeley-University musste LLC um das SNAP (SubNetwork Access Protocol) ergänzt werden, das seinerseits nichts anderes tut, als dem LLC das gute, alte EtherType-Feld zurückzubringen. Daraus ergibt sich die Situation, dass IP immer und ohne Ausnahme über ein Type-Feld läuft: Sei es das originale EtherType (im MAC-Header von Ethernet), oder sei es das neuere SNAP-Type (hinter LLC). Somit emuliert LLC-SNAP gegenüber IP auf Token-Ring gewissermaßen ein Ethernet (die erste Form der LAN-Emulation!), während LLC-SNAP auf Ethernet das Kuriosum erzeugt, dass das Ethernet mittels SNAP sich selbst emuliert, was schlicht ein grandioser Unfug wäre und auch darum kaum genutzt wird. Salopp gesagt: Token-Ring-Netzwerker müssen also damit leben, dass sich die Ethernet-Welt keinen Deut um LLC und SNAP schert. Nur dort, wo es denn gar nicht anders geht (z.B. beim Gerätemanagement), tolerieren die Ethernet-Netzwerker LLC+SNAP. Ansonsten wird das als Token-Ring-Spinnerei bzw. als überflüssiger Ballast (Overhead) abgetan.

Kapitel 13 • Token-Ring

321

Wer also LAN-Analyse im Token-Ring gelernt hat, muss ggf. im Ethernet umdenken. Insbesondere SNA-Techniker, die Data Flow Control hauptsächlich bei LLC kennen und schätzen gelernt haben (das ist durchaus nicht ironisch gemeint), müssen nun auf TCP umlernen. Es sei auf die entsprechenden Darstellungen in den vorangegangenen Kapiteln sowie in den TCP/IP-Kapiteln verwiesen.

13.12 Transparent vs. Source-Route Bridging Im Kapitel über Ethernet-Analyse wurde auf das sog. Transparent Bridging eingegangen, wie es sich mit dem Spanning Tree Algorithm und den BPDUs in der Ethernet-Welt entwickelt hat. Es sei darauf hingewiesen, dass Transparent Bridging nicht allein Ethernettypisch ist, sondern in gewisser Weise auch IP-typisch (insofern IP letztlich wiederum Ethernet-typisch ist bzw. auf Ethernet entwickelt wurde). Wir haben erörtert, dass gleichzeitiges Routing auf Layer 2 (Token-Ring SourceRouting) und Layer 3 (IP, IPX) zu schweren Fehlern bzw. höchst unerwünschten Erscheinungen führen kann, da sich mit den verschiedenen Routing-Systemen auch ein erheblich unterschiedlicher Umgang mit dem Mittel des Broadcasts verbindet. Sollte in einer Token-Ring-Umgebung, in der mit IP gearbeitet wird, unverzichtbar (nicht nur mit Routern, sondern auch) mit Bridges gearbeitet werden (müssen), so sollte dringend erwogen werden, die Brücken von Source-Route Bridging umzustellen auf Transparent Bridging. Im Zuge einer solchen Umstellung geht zwar die Token-Ring-Redundanz verloren, desgleichen das sog. Load Balancing. Da diese Elemente in jüngerer Zeit jedoch sowieso immer seltener eine Rolle spielen, sollte die Konkurrenz zweier verschiedener Routing- und Broadcast-Systeme bei Verwendung von IP zu dessen Gunsten behoben werden.

13.13 TokenSwitching Wo immer es im Token-Ring Backbone eng wird, bleibt nichts anderes übrig, als auf Switching umzusteigen. TokenSwitches sind heute ausgereifte Komponenten, die wacker ihre Arbeit tun. Wo früher FDDI-Backbones verlegt wurden, wird heute oft eher zu TokenSwitching gegriffen (oder zu Fast Ethernet bzw. Gigabit Ethernet). Aber: Wenn die alte LAN-Technik dazu herabgestuft wird, nur noch den Zugang zum Switched Backbone zu verschaffen, verliert ein so umfangreiches und altertümliches Token-Protokoll schlicht jeden Sinn.

322

Ausblick: Der Ring lebt (noch)

Das Token-Ring MAC-Protokoll ist ein Shared Media Protocol – und das passt in die Welt der LAN-Switches in keiner Weise hinein. In gewisser Weise gilt das zwar auch für das CSMA/CD von Ethernet, dass ein Shared Media Protocol ist – aber wie im Kapitel über Ethernet-Analyse bereits geschildert, eignet sich das alte CSMA/CD bestens für ein wirkungsvolles Switching: das ist der Zufall der Geschichte. Doch zurück zu Token-Ring: Wozu soll ein Token-Ring-Adapter, der unmittelbar an einem Switch-Port hängt, •

... beim Einschalten nach der aktuellen Ringgeschwindigkeit suchen (Frequenzkonflikt mit anderen Adaptern ist unmöglich, und der Switch stellt sich entsprechend ein)?

•

... nach einem Active Monitor suchen (der ist total überflüssig geworden)?

•

... nach einem Ring Parameter Server suchen (der ebenfalls total überflüssig geworden ist)?

Wozu gibt es denn noch einen komplexen Fehlererkennungs- und -behebungsapparat innerhalb der Adapter-Hardware, wenn sie am Switch-Port schlagartig zu 100% überflüssig und sinnlos geworden ist? Wozu sollen bei jedem Token-Ring-Adapter alle diese zwar ausgefeilten, aber am Switch-Port zu 100% wirklich völlig anachronistisch gewordenen Fähigkeiten bezahlt werden? Wozu müssen neuere Gerätegenerationen (was immer da auch nach der Generation der TokenSwitches kommen mag) sich dem völlig veralteten 16-Mbps-Adapter anpassen, der immer noch so tut, als lebte er in der Steinzeit? Warum kann man nicht einfach einen »saudummen« Ethernet-Adapter nehmen, dem es völlig egal ist, welche wie vielte Variante des Subraum-Frequenz-Traktorstrahl-Beamers in seinem Hub arbeitet !? Es ist kein Wunder, dass viele Token-Ring Backbones zu ATM hinmigrieren, andere wiederum zu Gigabit-Ethernet. Bei allen Schwächen dieser neuen Techniken: Sie sind schneller, teilweise auch billiger, ihre Entwicklung verheißt in der Zukunft mehr Dynamik, und damit auch mehr Nutzen. Wozu dann also überhaupt noch Token-Ring??

13.14 Ausblick: Der Ring lebt (noch) Diese Darstellung konnte unmöglich alle Facetten des Token-Ring-Protokolls berücksichtigen. Insbesondere das äußerst komplexe MAC-Protokoll wurde hier nur gezeigt, insofern es die wichtigsten Arbeitsschritte im Zuge einer Messung berührt.

Kapitel 13 • Token-Ring

323

Heute praktisch gänzlich unwichtige Aspekte wie z.B. das Early Token Release wurden vollständig ausgelassen, da sie nur Raum eingenommen, aber mangels Anwendbarkeit nicht geholfen hätten (in den heutigen Mini-Ringen kommt Early Token Release gar nicht zum Zuge). Auch die Formeln und Fehler in der alten Längenberechnung der IBM-Kabel haben wir uns hier mangels Aktualität erspart. Allen Zweiflern sei gesagt: Jawohl, dem Ethernet gehört die Zukunft! Der Token-Ring hingegen lebt insbesondere bei Banken und Versicherungen weiter, und das vor allem in Europa (und dort wiederum am stärksten in Deutschland). Ethernet, ATM und Fibre Channel gehören der Markt der unmittelbaren Zukunft. Für Token-Ring wird es schwer. Wo SNA noch existiert, kann Token-Ring noch lange bleiben; in der Client-Server-Landschaft ist der Siegeszug von Ethernet nicht zu bremsen. Es sei für alles Weitere ausdrücklich verwiesen auf die Protokoll-Dokumentation auf der beiligenden CD-ROM sowie im Internet: http://www.synapse.de/ban/

Kapitel 14 LLC: Logical Link Control 14.1 14.2 14.3 14.4

LCC-Treibervarianten LLC auf OSI Layer 2b: Abstraction Layer Der LLC-Header (PCI) LLC-Analyse

326 328 328 335

326

14.1

LCC-Treibervarianten

LCC-Treibervarianten In den frühen Tagen des LANs entwickelten wesentlich Microsoft und IBM die Technik für das PC-LAN, das als sog. Peer-to-Peer-Network arbeitete: Jeder konnte mit jedem Verbindung aufnehmen. Das von SNA-SDLC entlehnte LLC hatte gegenüber der Übertragung von SNATerminal-Daten durch SDLC die erweiterten Fähigkeiten, die für PC-LANs notwendig waren.

14.1.1 LLC und NetBIOS Da für den PC-Einsatz im LAN die neue NetBIOS-Schnittstelle geschaffen wurde (Network Basic Input/Output System), wurden LLC+NetBIOS gemeinsam ein stark verbreiteter Standard für lokale Netzwerke. Diese alte PC-Netzwerktechnik ist heute nicht mehr (oder kaum noch) im Einsatz.

14.1.2 LLC und NetBEUI Da für die Netzwerkapplikationen die eher simple NetBIOS-Schnittstelle schon bald erweiterungsbedürftig wurde, kam zu NetBIOS noch das Client-Server-Protokoll SMB (Server Message Block) hinzu. In der heutigen Windows-Welt wird diese Treiberkonstruktion (LLC+NetBIOS+SMB) als NetBEUI bezeichnet: NetBIOS Extended User Interface. Es sei auf die späteren Kapitel verwiesen, die sich mit Microsoft Networking beschäftigen.

14.1.3 LLC und DLC In seiner ältesten Rohfassung, also ohne NetBIOS, tritt LLC heute in aller Regel nur noch in zwei Zusammenhängen auf: •

SNA Terminal Sessions

•

Hewlett Packard Printing

In der Microsoft Windows-Welt wird diese gewissermaßen »rohe« Form des LLC-Einsatzes als DLC Protocol bezeichnet (Data-Link Control Protocol). Diese Bezeichnung als DLC ist etwas missverständlich, denn DLC ist nichts anderes als LLC pur. Die einzige Besonderheit liegt darin, dass bei DLC nicht das für Client-Server-Anwendungen typische LLC-I verwendet wird, sondern das wesentlich aus der SNA-Welt stammende LLC-II.

Kapitel 14 • LLC: Logical Link Control

327

14.1.4 LLC-1 (CLLS) und LLC-2 (COLS) Es gibt verschiedene Varianten von LLC: •

LLC-1 = CLLS = Connectionless Link Services

•

LLC-2 = COLS = Connection-Oriented Link Services

•

LLC-3 = CALS = Connectionless Acknowledged Link Services

LLC-3 erlangte keine sonderliche Bedeutung mehr (verbindungslos, aber mit Quittungen); dies gilt auch für ein ehemals vorgesehendes LLC-4 (Polling). Zum historischen Verständnis: Bei SNA wurde unterhalb der SNA-Protokolle eine Treiberschicht benötigt, welche die Funktionalität der Data Flow Control bereitstellte. Hier wurde zunächst SDLC (Synchronuous Data-Link Control) verwendet; später übernahm in Token-Ring-LANs LLC diese Aufgabe, und zwar in der Variante LLC-2. LLC-2 arbeitet wie alle Protokolle mit Data Flow Control verbindungsorientiert (connection-oriented); darum wird die Funktionalität von LLC-2 auch bezeichnet als Connection-Oriented Link Service (COLS). Dieser historisch als Normalfall angesehende LLC-Modus war in der EthernetWelt bzw. Client-Server-Welt von deutlich geringerer Bedeutung, manchmal sogar hinderlich, da die notwendige Data Flow Control dort auf der Transportschicht (Layer 4) erledigt wurde (wird), etwa durch TCP oder SPX. Der Unterschied dieser beiden Formen der Data Flow Control (DFC) war bzw. ist, dass DFC auf Layer 4 von Ende-zu-Ende reicht, also zwischen zwei Kommunikationsendpunkten betrieben wird, ungeachtet aller Transitnetze und RoutingVorgänge, während DFC auf Layer 2 nur im engen Radius des LANs arbeiten kann (sofern nicht auf WAN-Seite mit Remote Bridges gearbeitet wird an Stelle von Routern, was sich aus Gründen der Redundanz aber nicht durchsetzte). Eine auf Layer 2 mit LLC-2 ablaufende Datenfluss-Sicherung hatte in der Ethernet-Welt bzw. der Client-Server-Welt nur Bedeutung, wenn es galt, einen Router mit geringer WAN-Bitrate vor Buffer Overflow zu schützen, indem LAN-seitig der Client eine LLC-2-Verbindung zum Router und dieser darum die Möglichkeit hatte, sich vor Überlastung zu schützen. (Schutz vor Überlastung ist eine vorrangige Aufgabe jedweder Data Flow Control.) Diese Anwendungsform von LLC-2 in IP- und IPX-Netzen ist heute praktisch verschwunden, da mit ISDN und ATM längst WAN-seitig genügend Bitrate zur Verfügung steht. Eine Ausnahme stellt NetBIOS dar, das beide Varianten von LLC verwenden kann. Entsprechend dieser beiden Möglichkeiten von NetBIOS, verbindungslos oder verbindungsorientiert zu arbeiten, hat Microsoft mit NetBT (NetBIOS over TCP/IP) die beiden Varianten implementiert, NetBIOS mal über TCP (verbindungsorientiert) und mal über UDP (verbindungslos) zu transportieren.

328

LLC auf OSI Layer 2b: Abstraction Layer

So kann man heute bei LLC folgende Faustregel anwenden: LLC-Typ

Anwendungsform

LLC-1 = CLLS

Client-Server-Architekturen mit IP/IPX und/oder Ethernet. Verbindungsloses NetBIOS, auch bezeichnet als NetBIOS-NS (Non-Session bzw. Name Service) und NetBIOS-DGM (Datagram).

LLC-2 = COLS

SNA-Terminal-Sessions oder Hewlett-Packard-Printer. Verbindungsorientiertes NetBIOS, auch bezeichnet als NetBIOS-SSN (Session).

Tab. 14.1: LLC-1 und LLC-2 mit ihren überwiegenden Anwendungsformen

14.2

LLC auf OSI Layer 2b: Abstraction Layer Im heutigen Sprachgebrauch hätte man ein neu entwickeltes LLC als Abstraction Layer bezeichnet: Die Hardware der LAN-Adapter (samt ihrer Treiber) sowie die Software der Protokolltreiber ab der Netzwerkschicht (und höher) werden getrennt, sie »sehen« sich nicht mehr unmittelbar. LLC legt sich zwischen Netzwerk-Hardware und Treiber-Software und gibt beiden Seiten eine universelle, immer gleich bleibende Schnittstelle, über die den Programmierern Planungssicherheit sowie die Einfachheit eines modularen Systems gegeben wird: So braucht(e) der IP-Treiber nicht etwa jeweils neu programmiert zu werden, um ihn an Ethernet, Token-Ring und FDDI anzupassen. Die Hersteller der LAN-Adapter liefern die LLC-Kompatibilität mit, und damit die Kompatibilität zu den Treibern der höheren Schichten, die sich nur auf LLC bzw. SNA einzustellen brauchen und nicht etwa auf die ggf. wechselnde Hardware der LAN-Adapter darunter.

14.3

Der LLC-Header (PCI) Der LLC-Header bzw. die LLC-PCI (Protocol Control Information) ist zunächst einmal sehr simpel aufgebaut:

Abb. 14.1: Der LLC-Header (PCI)

Kapitel 14 • LLC: Logical Link Control

329

14.3.1 Service Access Points (SAP) Zunächst sind zwei SAPs gegeben (Destination/Source Service Access Point), die das oberhalb von LLC arbeitende Protokoll seitens Absender und Empfänger adressieren; Beispiel: SAP=0xE0 für NetWare IPX oder SAP=0xF0 für NetBIOS. DSAP Der DSAP (Destination SAP) ist wie folgt formatiert:

Abb. 14.2: LLC DSAP – Destination Service Access Point

Zunächst kommt das auch bei MAC-Adressen übliche I/G-Bit (Individual or Group Address), mit dem angezeigt wird, ob ein individueller SAP (EinzelAdresse) oder ein Multicast-SAP (Gruppenadresse) angesprochen wird. Das U-Bit kennzeichnet eine User Defined Address. Die D-Bits enthalten die eigentliche Destination Address. SSAP Der SSAP (Source SAP) ist wie folgt aufgebaut:

Abb. 14.3: LLC SSAP – Source Service Access Point

Protokolle mit Data Flow Control kennzeichnen in aller Regel die Richtung des Datenflusses bzw. unterscheiden zwischen Datenanforderung (Client oder Terminal) und Datenrückgabe (Server oder Host). Diese Unterscheidung findet durch das C/R-Bit statt: •

C/R = 0 = Command

•

C/R = 1 = Response

Eine unabhängig davon gesetzte Kennzeichnung der Datenflussrichtung ist mit dem P/F-Bit (Poll/Final) zusätzlich im Control-Feld gegeben.

330

Der LLC-Header (PCI)

Das U-Bit kennzeichnet eine User Defined Address. Die S-Bits enthalten die eigentliche Source Address.

14.3.2 Control Das Steuerfeld von LLC kann 1 Byte oder 2 Byte lang sein und ist hoch variabel. Die verschiedenen Bedeutungen dienen hauptsächlich folgenden Zwecken: •

Datenflusskontrolle/Data Flow Control

•

Session Management

Es sei bemerkt, dass es beachtenswert ist, wie mit nur zwei Oktetten im ControlFeld eine durchaus komplexe Sicherungslogik umgesetzt wurde. Im Folgenden werden die verschiedenen Varianten von LLC bzw. seines ControlFeldes LPDU genannt: LPDU = LLC PDU = Logical Link Control Protocol Data Unit Eine Eselsbrücke hilft, den Aufbau des Control-Feldes im Gedächtnis zu behalten: LLC-Variante

Länge des Control-Feldes

LLC-1 = CLLS

Control = Länge von 1 Oktett

LLC-2 = COLS

Control = Länge von 2 Oktetten

Tab. 14.2: Die Länge des Control-Feldes und die LCC-Typen

LLC-1 U-Format: Unnumbered Information

Abb. 14.4: Das Control-Feld von LLC-1 mit U-Format

Arbeitet LLC verbindungslos (CLLS – Connectionless Link Services), so ist das Control-Feld nur 1 Byte lang (U-Format LLC). Die ersten zwei Bits mit Wert »11« legen die Variante Unnumbered Information fest. Der Hinweis auf »nicht durchgezählt« bedeutet, dass die LLC-Pakete nicht durchgezählt werden, dass also keine LLC Sequence Numbers enthalten sind wie bei LLC-2.

Kapitel 14 • LLC: Logical Link Control

331

P/F-Bit Das P/F-Bit (Poll-Final) kennzeichnet nach Bedarf die Flussrichtung. M-Bits Die M-Bits (Modifier Function Bits) kennzeichnen die Unterfunktionen des UIPaketes: Belegung der M-Bits

Bedeutung/Funktion

MM-MMM = 00-000

= UI- Unnumbered Information

MM-MMM = 11-101

= XID – Exchange Identification

MM-MMM = 00-111

= TEST – Test

MM-MMM = 11-110

= SABME – Set Asychronous Balanced Mode Extended

MM-MMM = 00-110

= UA – Unnumbered Acknowledgment

MM-MMM = 11-000

= DM – Disconnected Mode

MM-MMM = 00-010

= DISC – Disconnect

MM-MMM = 10-001

= FRMR – Frame Reject

Tab. 14.3: Belegung der M-Bits im Control-Feld von LCC-1 (U-Format)

Einige Funktionen sind SNA-typisch wie beispielsweise XID (Aushandeln der Session- bzw. Terminal-ID); andere sind im Verwendungszweck universell wie etwa FRMR (Zurückweisung eines LLC-Paketes wegen eines Fehlers). LLC Type 1 – U-Format – DISC Eine DISC-LPDU (Disconnect LLC PDU) wird gesendet, um eine (per SABMELPDU gestartete) Operation im Asynchronous Balanced Mode zu beenden; der Partnerstation (Remote Link Station) wird damit gleichzeitig mitgeteilt, dass sie in den Asynchronous Disconnected Mode wechseln möge. Die Remote Link Station antwortet darauf entweder mit einem Unnumbered Acknowledgment (UA-LPDU Response), sofern sie sich im Asynchronous Balanced Mode befindet, oder mit einer DM-PDU (Response), sofern sie sich im Asynchronous Disconnected Mode befindet. LLC Type 1 – U-Format – DM Mit einer DM-LPDU (Disconnected Mode LLC PDU) teilt eine LLC-Station mit, dass sie logisch abgemeldet ist (Logically Disconnected). LLC Type 1 – U-Format – FRMR Eine FRMR-LPDU (Frame Reject LLC PDU) wird gesendet, um mitzuteilen, dass eine empfangene LPDU fehlerhaft war.

332

Der LLC-Header (PCI)

LLC Type 1 – U-Format – SABME Eine SABME-LPDU (Set Asynchronous Balanced Mode Extended LLC PDU) wird gesendet, um sich mit einer Remote Link Station darauf zu verständigen, Datenaustausch im Extended Asynchronous Balanced Mode durchzuführen. Die Remote Link Station muss hierauf mit einer UA-LPDU (Bestätigung) oder einer DM-LPDU (Ablehnung) antworten. LLC Type 1 – U-Format – TEST Die TEST-LPDU (Test LLC PDU) kann Testzeichen im INFORMATION-Feld (dem Datenfeld des LLC-Paketes) übertragen, muss dieses aber nicht. Wenn ja, müssen diese Testzeichen von der Partnerstation ohne Änderung zurück gesendet werden. Diese Funktion könnte man mit dem bekannten »Ping« aus der IP-Welt vergleichen. LLC Type 1 – U-Format – UA Eine UA-LPDU (Unnumbered Acknowledgment LLC PDU) (Response) wird gesendet, um eine SABME-LPDU oder DISC-LPDU zu bestätigen. LLC Type 1 – U-Format – XID Eine XID-LPDU (Exchange Identifier LLC PDU) enthält Paramenter der Datenflusskontrolle. Bei SNA wird hiermit zwischen SNA-Host (bzw. SNA-Gateway) und dem SNA-Terminal die Terminal-Session-ID zugewiesen. LLC-2 I-Format: Information Transfer

Abb. 14.5: Das Control-Feld von LLC-2 mit I-Format

Arbeitet LLC verbindungsorientiert (COLS – Connection-Oriented Link Services), so ist das Control-Feld 2 Byte lang (I-Format LLC). Das erste Bit mit Wert »0« legt die Variante Information Transfer fest. Die Paketnummern (Sequence Numbers) stellen eine zentrale Funktion der Datenflusskontrolle innerhalb der laufenden Übertragung dar. Sie sind nicht zu verwechseln mit den Funktionen zur Session Control (Sitzungssteuerung), die nur im S-Format von LLC gegeben sind (s.u.).

Kapitel 14 • LLC: Logical Link Control

333

P/F-Bit Das P/F-Bit (Poll-Final) kennzeichnet die Flussrichtung. N(s)-Bits Die sieben N(s)-Bits enthalten den LLC-Sende-Sequenz-Zähler (Transmitter Send Sequence Number). Dies ist die laufende Paketnummer des Absenders (gemäß P/F-Bit). N(r)-Bits Die sieben N(r)-Bits enthalten den LLC-Empfangs-Sequenz-Zähler (Transmitter Receive Sequence Number). Dies ist die laufende Paketnummer des Empfängers (gemäß P/F-Bit). LLC-2 S-Format: Supervisory Information

Abb. 14.6: Das Control-Feld von LLC-2 mit S-Format

Arbeitet LLC verbindungsorientiert (COLS – Connection-Oriented Link Services), so ist das Control-Feld 2 Bytes lang (S-Format LLC). LPDUs im S-Format haben kein Feld INFORMATION (kein Datenfeld hinter LLC), da sie sich nur mit dem Bereitschaftszustand der Stationen befassen. LPDUs im S-Format übertragen also keine Protokolle höherer Schichten und auch keine Nutzdaten; sie dienen allein der Datenflusskontrolle. Die ersten zwei Bits mit Wert »10« legen die Variante Supervisory Information fest. P/F-Bit Das P/F-Bit (Poll-Final) kennzeichnet die Flussrichtung. N(r)-Bits Die sieben N(r)-Bits enthalten den LLC-Empfangs-Sequenz-Zähler (Transmitter Receive Sequence Number).

334

Der LLC-Header (PCI)

S-Bits Die S-Bits (Supervisory Function Bits) legen die jeweilige Funktion der Data Flow Control fest. Belegung der S-Bits

Bedeutung/Funktion

SS = 00

= RR – Receive Ready

SS = 01

= RNR – Receive Not Ready

SS = 11

= REJ – Reject

Tab. 14.4: Belegung der S-Bits im Control-feld von LCC-2 (S-Format)

LLC Type 2 – S-Format – RR Mit einer RR-LPDU (Command/Response) teilen sich LLC-Stationen mit, dass sie bereit sind, eine weitere LPDU im I-Format zu empfangen. Entweder werden alle bislang eingetroffenen I-Format-LPDUs auf diesem Wege durch den Wert von N(r) bestätigt und der Empfang weiterer I-Format-LPDUs freigestellt, oder eine Station, die bislang am Empfang gehindert war, teilt mit, dass sie nunmehr empfangsbereit ist. LLC Type 2 – S-Format – RNR Die RNR-LPDU (Receive Not Ready) zeigt an, dass der Absender nicht empfangsbereit ist, also keine weiteren I-Format-LPDUs annehmen kann. Alle fehlerfrei bereits empfangenen LPDUs im I-Format werden über den Wert von N(r) bestätigt. Weiterhin bei der empfangsgestörten Station eingehende LPDUs im I-Format werden nicht angenommen und müssen vom Absender nochmals gesendet werden, nachdem über eine RR-LPDU die neuerliche Empfangsbereitschaft angezeigt wurde. LLC Type 2 – S-Format – REJ Mit einer REJ-LPDU (Reject) kann eine Station, die nicht alle eingegangenen I-Format-LPDUs einwandfrei empfangen konnte, die fehlenden I-Format-LPDUs nachfordern. Alle fehlerfrei bereits empfangenen LPDUs im I-Format werden über den Wert von N(r) bestätigt. Es kann keine zweite REJ-LPDU gesendet werden, bevor nicht auf die erste geantwortet wurde.

Kapitel 14 • LLC: Logical Link Control

14.4

335

LLC-Analyse In den meisten Fällen wird LLC in der Variante von LLC-1 verwendet, und dann auch nur in der Funktion UI (Unnumbered Information), also nur für Übertragungen außerhalb logischer Sitzungen und ohne Quittungsverkehr. Das Control-Feld hat dann immer den Wert 0x03. Der folgende Filter wirkt sowohl bei Ethernet also auch bei Token-Ring, sofern bei Token-Ring kein Source-Routing verwendet wird. Filter auf (Protokoll-Feld/Parameter) ...

Offset

Wert (hex)

LLC Control = UI = Unnumbered Information

16

0x03

Tab. 14.5: Filter auf LCC-1 (U-Format) mit UI-Frames

Ein typisches Beispiel für LLC ist in Abbildung 14.7 zu sehen; in diesem Beispiel wird eine SNA-Session übertragen:

Abb. 14.7: LLC mit SAP 0x04 (SNA)

336

LLC-Analyse

Es ist gut zu erkennen, dass LLC mit Data Flow Control durch Paketnummerierung mittels N(s) und N(r) arbeitet, wobei N(s) den Paketzähler des Senders (Transmitter Send Sequence Number) und N(r) den Paketzähler des Empfängers (Transmitter Receive Sequence Number) darstellt. Aus Erfahrung kann der Autor sagen, dass Fehler auf LLC-Ebene eine extreme Seltenheit sind. Dies mag schon darin begründet sein, dass LLC mit DatenflussSteuerung bereits eine Ausnahme an sich darstellt. Es mag aber auch daran liegen, dass die Überschaubarkeit des Protokolls den Programmierern weniger Gelegenheit zu Fehlern gibt.

Kapitel 15 SNAP: SubNetwork Access Protocol 15.1 15.2

Wozu SNAP? SNAP-Analyse

338 339

338

15.1

Wozu SNAP?

Wozu SNAP? SNAP wurde entwickelt, um die zu schmale Basis der LLC-SAPs wieder zu verbreitern. Es hatte sich herausgestellt, dass einerseits die Zahl der Protokolle größer war, als sie durch die 8-Bit-SAPs (eigentlich: 6-Bit-SAPs) darstellbar war, dass aber andererseits auch grundsätzlich angenehm war, den Protokollen der TCP/IP-Familie das alte EtherType-Feld wieder zurückzugeben. Aber auch Erwägungen, dass eine Erweiterung der Möglichkeiten im Bereich des Netzwerkmanagements gut täte, haben dann zum LLC-Anhang SNAP geführt. So wurde einerseits mit SNAP das alte EtherType-Feld zurückgeholt, andererseits wurde auf LLC-Ebene eingeführt, was auf MAC-Ebene bereits bekannt war, nämlich ein »Organizationally Unique Identifier«: Vor das SNAP-Type-Feld (2 Bytes) wurde ein »OUI«-Feld gesetzt (3 Bytes), das auch schon mal als »Protocol Family ID« bezeichnet wird: Es handelt sich um eine 3-Byte-Kennung, wie sie auch in jeder MAC-Adresse vorhanden ist, mit der Unternehmen bzw. Hersteller oder Protokollfamilien (wie z.B. AppleTalk) gekennzeichnet werden.

Abb. 15.1: Der SNAP-Header (PCI)

Der LLC-SAP für SNAP beträgt 0xAA. Da bei Verwendung von LLC hauptsächlich die TCP/IP-Protokolle über SNAP arbeiten (nur wenige andere Protokolle sonst noch), ist ein Filter auf die SAP-ID 0xAA besonders leicht zu setzen: Filter auf (Protokoll-Feld/Parameter) ...

Offset

Wert (hex)

LLC mit SNAP

14

0xAAAA

Tab. 15.1: Filter auf LCC-SNAP

Kapitel 15 • SNAP: SubNetwork Access Protocol

15.2

339

SNAP-Analyse SNAP ist aus der Sicht der Analyse langweilig: Es gilt für das SNAP-Type-Feld entsprechend, was bereits für das EtherType-Feld im Kapitel zur Ethernet-Analyse gesagt wurde. Da für die TCP/IP-Protokolle gilt, dass die SNAP Protocol ID (OUI) in den ersten drei Bytes auf 0x000000 gesetzt wird, ist auch hier nichts Aufregendes zu verzeichnen. So besteht der SNAP-Inhalt bei der Übertragung von TCP/IP aus folgenden ByteKetten: Filter auf (Protokoll-Feld/Parameter) ...

Offset

Wert (hex)

LLC + SNAP

14

0xAAAA03

LLC + SNAP + IP

14

0xAAAA03 000000 0800

LLC + SNAP + ARP

14

0xAAAA03 000000 0806

Es ist sinnvoll, den Filter nur auf 0xAAAA03 oder 0xAAAA zu setzen: So können sowohl IP wie auch ARP »eingefangen« werden; IP ohne ARP kann zu Fehlern in der Deutung der Vorgänge führen; ARP ohne IP ist nur bei gezielter Suche nach Fehlern in der Adressauflösung ausnahmsweise sinnvoll. Das dritte Byte in der Folge 0xAAAA03 steht für »Unnumbered Information« (UI), wie oben im LLC-Abschnitt erläutert: Da TCP über eine eigene Data Flow Control verfügt, werden auf LLC-Ebene die Pakete ohne Nummerierung und ohne Staukontrolle verschickt bzw. empfangen. Ein »wilder Filter« auf SNAP ohne Offset-Angabe könnte so aussehen ...

Abb. 15.2: Filter auf LLC-SNAP (1)

340

SNAP-Analyse

... oder so:

Abb. 15.3: Filter auf LLC-SNAP (2) mit EtherType für ARP

Ein typischer SNAP-Header könnte dann so aussehen:

Abb. 15.4: LLC-SNAP mit ARP

In Abbildung 15.4 lässt sich unten im sog. Hex-Dump-Fenster vor dem SNAPHeader mit 0x0000000806 die Kennung 0x03 für LLC-UI (Unnumbered Information) erkennen.

Kapitel 16 TCP/IP – Die DoD-Protokolle 16.1 16.2 16.3 16.4 16.5 16.6 16.7 16.8 16.9 16.10 16.11

Einführung: Was ist TCP/IP? Die wichtigsten Protokolle der TCP/IP-Familie im Überblick Vorgehensweise Adress- und Namensauflösung Routing-Fehler/Default Gateway Im Fokus des Analyzers: ICMP Im Fokus des Analyzers: IP Im Fokus des Analyzers: TCP Im Fokus des Analyzers: UDP BOOTP/DHCP SNMP/RMON

342 349 361 361 370 375 384 410 441 443 450

342

16.1

Einführung: Was ist TCP/IP?

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.

16.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 Quittungsund Ü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). 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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

343

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. 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 Program« (UDP, siehe unten). Jetzt, da dies geschafft ist, blüht Ihr Unternehmen, und Sie freuen sich über Ihren Erfolg.

344

Einführung: Was ist TCP/IP?

16.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.

16.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? 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 255-stellig, was einen riesigen Nummernraum erschloss.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

345

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 5stelligen 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«). 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.

346

Einführung: Was ist TCP/IP?

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. 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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

347

16.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. 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.)

348

Einführung: Was ist TCP/IP?

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.

16.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 IP-Adresse? 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. 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.

16.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

Kapitel 16 • TCP/IP – Die DoD-Protokolle

349

(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!

16.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.

16.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. 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

Tab. 16.1: Die wichtigsten Protokolle des Internet im Überblick

350

Die wichtigsten Protokolle der TCP/IP-Familie im Überblick

Abkürzung

Protokoll

DHCP

= Dynamic Host Configuration Protocol

DNS

= Domain Name Service

WINS

= Windows Internet Name Service

SNMP

= Simple Network Management Protocol

RMON

= Remote (Network) MONitoring

Tab. 16.1: Die wichtigsten Protokolle des Internet im Überblick (Forts.)

16.2.1 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 Tab. 16.2: WinNT Registry Keys – TCP/IP

16.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).

Kapitel 16 • TCP/IP – Die DoD-Protokolle

351

Der ARP-Header hat folgenden Aufbau:

Abb. 16.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)

ARP Operation Code

16 Bit

Kennzeichnung der ARP-Funktion: 0 = ARP Request 1 = ARP Reply 2 = RARP Request 3 = RARP Reply

Tab. 16.3: ARP – Übersicht zu den Parametern des Protokoll-Headers

352

Die wichtigsten Protokolle der TCP/IP-Familie im Überblick

ARP Parameter

Länge

Bedeutung

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

Tab. 16.3: ARP – Übersicht zu den Parametern des Protokoll-Headers (Forts.)

16.2.3 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:

Abb. 16.2: Der IPv4-Header (PCI)

Kapitel 16 • TCP/IP – Die DoD-Protokolle

353

IPv4 Parameter

Länge

Bedeutung

IP Version

4 Bit

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

13 Bit

Im Falle des Zerlegens von IP-Paketen in Fragmente besagt der Offset-Wert, welche Startposition das aktuelle Fragment im Originalpaket hat(te).

Tab. 16.4: IPv4 – Übersicht zu den Parametern des Protokoll-Headers

354

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 IP-Paket ü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 IP-Header 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.

Tab. 16.4: IPv4 – Übersicht zu den Parametern des Protokoll-Headers (Forts.)

16.2.4 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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

355

Der ICMP-Header hat folgenden Aufbau:

Abb. 16.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 ICMPNachricht

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.

Tab. 16.5: ICMP – Übersicht zu den Parametern des Protokoll-Headers

356

Die wichtigsten Protokolle der TCP/IP-Familie im Überblick

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. 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

Tab. 16.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

03

(Code ist ohne Bedeutung)

Host, Router

Destination Unreachable/Unzustellbar 0

Netz ist nicht erreichbar

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

Tab. 16.7: ICMP Code-Werte

Router

Kapitel 16 • TCP/IP – Die DoD-Protokolle

Type

Code

Bedeutung

0

Datagramm konnte nicht bearbeitet werden

04

357

Absender

Source Quench/Überlastung durch Sender

05

Host, Router

Redirect/Umleitung der Datagramme ... 0

... zu einem bestimmten IP-Netz

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

Router

Echo Request/Anforderung 0

09

(ohne Bedeutung)

Host, Router

Router Advertisement Message 0

10

Bekanntmachung eines Routers

Router

Router Solicitation Message 0

11

Aufforderung an Router, sich zu melden

Host, Router

Time Exceeded/Zeitüberschreitung 0

TTL auf 0 gefallen/IP-Paket wurde verworfen

Router

1

Reassembly-Timer abgelaufen (Fragmentation)

Router

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

Code-Wert entspricht Zahl der Subnet-Mask-Bits

Host, Router

Tab. 16.7: ICMP Code-Werte (Forts.)

Die Analyse von IP-Netzwerken arbeitet stark mit der Auswertung von ICMPMeldungen. Hierzu sei auf die nachfolgenden Abschnitte verwiesen.

358

Die wichtigsten Protokolle der TCP/IP-Familie im Überblick

16.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:

Abb. 16.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ängers

TCP Sequence Number

32 Bit

Startposition im Byte-Strom des Absenders. Der Absender gibt an, ab welchem Offset der zu sendenden Datenmenge dieses Paket beginnt.

Tab. 16.8: TCP – Übersicht zu den Parametern des Protokoll-Headers

Kapitel 16 • TCP/IP – Die DoD-Protokolle

359

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.

Tab. 16.8: TCP – Übersicht zu den Parametern des Protokoll-Headers (Forts.)

360

Die wichtigsten Protokolle der TCP/IP-Familie im Überblick

Eine ausführliche Erklärung der Wirkungsweise von TCP und seiner Parameter ist in Abschnitt 16.8.1 zu finden.

16.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:

Abb. 16.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 UDP-Pseudo-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

Tab. 16.9: UDP – Übersicht zu den Parametern des Protokoll-Headers

16.2.7 Details und weitere Protokolle Die vollständige Beschreibung der Protokolle ist auf der Beilage-CD-ROM zu finden oder im Internet unter: http://www.synapse.de/ban/

Kapitel 16 • TCP/IP – Die DoD-Protokolle

16.3

361

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. Grundsätzlich kann man folgende Fehlerquellen abstrakt in Klassen fassen und die daran beteiligten Protokolle eingrenzen: OSI Layer

Fehlerklasse, Protokolle, betroffene OSI Layer

A

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)

Tab. 16.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. Im Kapitel »Grundlagen der Methodik« sind die wichtigsten Hinweise für das grundlegende Vorgehen beschrieben. 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.

16.4

Adress- und Namensauflösung Um Fehler in der Adress- und Namensauflösung zu finden, müssen die zuständigen Protokolle überwacht werden.

16.4.1 Betriebsphase Hierbei ist zu unterscheiden, in welcher Phase des Netzbetriebes ein Rechner unter Störungen zu leiden hat:

362

Adress- und Namensauflösung

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

Tab. 16.11: Fehler in der Adress- und Namensauflösung je nach Betriebsphase

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 IPAdresse 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 DHCPClients 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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

363

Die folgenden Szenarien sind typisch:

16.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-MAC-Adressen (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. 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 Treiber-Konfiguration) 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.

16.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

364

Adress- und Namensauflösung

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. 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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

365

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 IPAdressen 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-NT-Servers manuell ausgeschlossen werden. Wenn ein IP-Rechner mit der IP-Broadcast-Adresse arbeitet, wird dies zwei schwerwiegende Fehler zur Folge haben: 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 Listing 16.1: WinNT Registry-Einträge zu DHCP

366

Adress- und Namensauflösung

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\ Parameters\Tcpip\IPAddress Listing 16.1: WinNT Registry-Einträge zu DHCP (Forts.)

16.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 IPAdresse 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 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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

367

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 IP-Teilnehmer 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 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\ Parameters\Tcpip\SubnetMask HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\ Options\Option# Listing 16.2: WinNT Registry-Einträge zur IP Subnet Mask

368

Adress- und Namensauflösung

16.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) Listing 16.3: WinNT Registry-Einträge zum Computer-Namen/NetBIOS-Namen

16.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 Listing 16.4: WinNT Registry-Eintrag zum DNS-Namen

16.4.7 Die IP Address 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 DNS-Server erreichen; dies ist u.U. nicht der Fall.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

369

WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters\NameServer HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DHCP\Parameters\ Options\6 (= DNS Server) Listing 16.5: WinNT Registry-Einträge zur IP-Adresse des DNS-Servers

16.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).

16.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 RARP-Request 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 MACBroadcast-Verbindungen gab, könnten nun Wirkung zeigen. Dies wäre etwa

370

Routing-Fehler/Default Gateway

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. 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 Listing 16.6: WinNT Registry-Einträge zu ARP

16.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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

371

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 Tab. 16.12: WinNT Registry Keys – Default Gateway – IP Subnet Mask

16.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).

372

Routing-Fehler/Default Gateway

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 TraceRoute-Befehl: 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 16.12: WinNT Registry Keys – Default Gateway – IP Subnet Mask.

16.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 ICMPRü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«

•

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«

Kapitel 16 • TCP/IP – Die DoD-Protokolle

•

373

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 ARP-Broadcasts 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 16.13): Type

Code

Bedeutung

0

Netz ist nicht erreichbar

Router

1

Rechner ist nicht erreichbar

Router

4

Fragmentierung nötig, aber nicht gestattet

Router

5

Source Route nicht erreichbar

Router

03

Absender

Destination Unreachable/Unzustellbar

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

Tab. 16.13: ICMP-Meldungen von Routern wegen Paketverwerfung

Siehe hierzu auch: Tabelle 16.12: WinNT Registry Keys – Default Gateway – IP Subnet Mask.

16.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:

374

Routing-Fehler/Default Gateway

•

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 IPPakete 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. 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 16.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

Tab. 16.14: ICMP-Meldungen von Routern mit Umleitungsempfehlung

Kapitel 16 • TCP/IP – Die DoD-Protokolle

375

Zum Default Gateway und der IP Subnet Mask unter MS-Windows können die in Tabelle 16.12 aufgeführten Registry-Einträge zu Rate gezogen werden.

16.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.

16.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 MAC-Header ist zum Offset hinzuzuzählen (und beträgt 14 Byte, sofern ohne Token-Ring Source-Routing gearbeitet wird). Filter auf (Protokoll-Feld/Parameter) ...

Offset

Wert (hex)

Ethernet II + IP + ICMP

23

01

LLC-SNAP + IP + ICMP

28

01

Tab. 16.15: Filter auf ICMP (bei Token-Ring: ohne Source-Routing)

Abb. 16.6: Filter auf Pakete mit ICMP

376

Im Fokus des Analyzers: ICMP

Der ICMP-Filter sollte kombiniert werden mit einem Filter auf IP, weil der HexWert 0x01 am jeweiligen Offset sicher auch in anderen Paketen zufällig vorkommt. Besser ist ein Filter, dem vom Analyzer angeboten wird (Abbildung 16.6): Die ICMP-Meldungen sind wie folgt zu verstehen:

16.6.1 ICMP: »Destination Unreachable« Aus historischen Gründen werden zu den jeweiligen ICMP-Meldungen die UnixConfig-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

WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters\PersistentRoutes Listing 16.7: WinNT Registry-Eintrag zu statischen Routen

»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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

377

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 Listing 16.8: WinNT Registry-Einträge zu IP-Sicherheits-Filtern

Siehe auch die in Abbildung 16.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 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.

378

Im Fokus des Analyzers: ICMP

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 Listing 16.9: WinNT Registry-Einträge zu UDP-TCP Sicherheits-Filtern

16.6.2 ICMP: »Redirection – Gateway Address« Insofern die ICMP-Meldung »Network Unreachable« bereits einen Routing-Fehler 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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

379

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/IPTreiber 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:
        Das kann bestenfalls nur noch als schlechter Witz bezeichnet werden: Externe Dienstleister wie der Autor verdienen ihr Geld (auch) damit, dass sie ICMP-Meldungen 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 Listing 16.10: WinNT Registry-Einträge zum IP Default Gateway

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.

380

Im Fokus des Analyzers: ICMP

WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters\PersistentRoutes Listing 16.11: WinNT Registry-Eintrag zu statischen Routen

16.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«). 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 Listing 16.12: WinNT Registry-Einträge zu IP TTL (Time-To-Live)

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.

16.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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

381

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«).

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 16.12 aufgeführten Registry-Einträge zu Rate gezogen werden.

16.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.

382

Im Fokus des Analyzers: ICMP

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 Listing 16.13: WinNT Registry-Einträge zur MTU (Maximum Transmission Unit)

Hinweis Zum Default Gateway und der IP Subnet Mask unter MS-Windows können die in Tabelle 16.12 aufgeführten Registry-Einträge zu Rate gezogen werden.

16.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.

16.6.7 ICMP: »Echo Request/Echo Reply« Der allseits bekannte Befehl »ping« arbeitet mit den ICMP-Funktionen »Echo Request/Echoe Reply«.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

383

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 16.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/). 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 ICMP-Paket 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 Excee-

384

Im Fokus des Analyzers: IP

ded«. 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 DNS-Server 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 Listing 16.14: WinNT Registry-Einträge zum DNS-Server

16.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«. Na, prima – und noch falsch dazu! Auch wurde schon beobachtet, dass WinNTServer (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.

16.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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

385

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.

Abb. 16.7: IP Header im LANdecoder32 (IP over DIX/Ethernet II)

386

Im Fokus des Analyzers: IP

16.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.

Abb. 16.8: Filter auf IP mittels der Hex-Folge 0x080045

Der Vorteil dieser Filtervariante ist ein doppelter: Einerseits sind solche Hex-Filter oft schneller als vorgefertigte Filter des Analyzers (siehe unten, Abbildung 16.1), andererseits können sämtliche IP-Varianten (mit Ausnahme von NetwareIP) damit erwischt werden: •

IP über Ethernet II/DIX

•

IP über LLC-SNAP

•

IP-Header in ICMP-Meldungen (indirekt)

Kapitel 16 • TCP/IP – Die DoD-Protokolle

387

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.

Abb. 16.9: Filter auf IP/Angebot des Analyzers

16.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.

Abb. 16.10: IP-Parameter »Type of Service (ToS)«

388

Im Fokus des Analyzers: IP

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.

Tab. 16.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 Listing 16.15: WinNT Registry-Eintrag zum IP ToS (Type of Service)

16.7.3 IP: Total Length Im Gegensatz zum Parameter IP Header Length, der nur die Länge des IP-Headers 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:

Kapitel 16 • TCP/IP – Die DoD-Protokolle

•

389

IP Total Length = 40

Das setzt sich wie folgt zusammen: •

20 Byte entfallen auf den IP-Header.

•

20 Byte entfallen auf den TCP-Header.

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 16.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-TCP-Paket 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 16.11 ist eine Gesamtlänge von 1.500 Byte angegeben. Dies ist aus verschiedenen Gründen aufschlussreich:

Abb. 16.11: IP-Parameter »Total Length« bis »Time To Live«

390

Im Fokus des Analyzers: IP

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. 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

Kapitel 16 • TCP/IP – Die DoD-Protokolle

391

Das kann nicht stimmen. Der Ethernet-Header ist 14 Byte lang, der IP-Header 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:

Abb. 16.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?

392

Im Fokus des Analyzers: IP

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. 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.

16.7.4 IP: Fragment ID Mittels der IP Fragment ID (siehe Abbildung 16.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, 16.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 16.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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

393

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 IPHeader 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 16.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: •

IP Local Loop

•

IP Local Routing

•

Die Erkennung dieses Phänomens sollte durch automatische Routinen des Analyzers erfolgen (Experten-System), etwa wie in Abbildung 16.13 zu sehen.

Abb. 16.13: Automatische Erkennung von Local IP Loops durch ein Expertensystem

Das einschlägige Szenario wurde bereits im Abschitt 16.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.

394

Im Fokus des Analyzers: IP

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 IP-Paketes 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. 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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

395

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. 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.

Abb. 16.14: MS-Zählung der IP Fragment ID: 0xF837 > 0xF937

Die Abbildung 16.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 LoByte: Die Differenz beider ID-Werte beträgt genau 256 bzw. 0x0100.

16.7.5 IP: Fragmentation Flags Die sog. IP Fragmentation Flags erfüllen zwei Funktionen (siehe Abbildung 16.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

396

Im Fokus des Analyzers: IP

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. 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 IP-Pakete 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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

397

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 Listing 16.16: WinNT Registry-Einträge zur MTU und IP Fragmentation

16.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 16.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 IPPaketes 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.

398

Im Fokus des Analyzers: IP

Richtig ist, dass dies normalerweise so wäre; aber schon das Beispiel im Abschnitt 16.7.3 hat gezeigt, dass immer Vorsicht geboten ist. Ein gesundes Misstrauen zahlt sich über die Dauer immer aus.

16.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 16.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 IP-Paketes 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 Listing 16.17: WinNT Registry-Einträge zu IP TTL (Time-To-Live)

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). 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 16.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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

399

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: •

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.

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.

400

Im Fokus des Analyzers: IP

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 16.5.3). F. Routing-Fehler (3) In Anlehnung an das Beispiel im Abschnitt 16.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 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. 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 16.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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

401

16.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.

Abb. 16.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 Listing 16.18: WinNT Registry-Einträge zum IP Sicherheitsfilter

16.7.9 IP: Checksum Die IP-Prüfsumme wird von jedem Router neu berechnet, da ja jeder Router den TTL-Wert zu vermindern hat.

402

Im Fokus des Analyzers: IP

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.

16.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.

Abb. 16.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 16.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!

Kapitel 16 • TCP/IP – Die DoD-Protokolle

403

Abb. 16.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)

Abb. 16.18: Filter auf den Hex-Code einer IP-Adresse (ohne festen Offset)

404

Im Fokus des Analyzers: IP

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 16.18 zu sehen. Im Falle der Abbildung 16.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.

Abb. 16.19: Doppelte IP-Adresse (LANreport32 Expertendiagnose)

Kapitel 16 • TCP/IP – Die DoD-Protokolle

405

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. 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 IP-Adresse 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.

406

Im Fokus des Analyzers: IP

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: Ein solches Szenario fällt einfach mehr auf und ist schneller erkannt und behoben. Es sei auf den Abschnitt 16.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 Listing 16.19: WinNT Registry-Einträge zu IP Subnet Mask/Subnet Broadcast

16.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. 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 16.20 unten zu sehen sind, hängen von Einstellungen ab, die zuvor hinterlegt wurden. Über Schwellwerte wie die hier in Abbildung 16.21 kann genau gesteuert werden, wie viel Fehlertoleranz man selber akzeptieren möchte. So würde man bei WAN-

Kapitel 16 • TCP/IP – Die DoD-Protokolle

Abb. 16.20: Expertendiagnose von IP (hier: LANdecoder32)

Abb. 16.21: IP Expertenanalyse: Definition von Schwellwerten zur Qualitätssicherung

407

408

Im Fokus des Analyzers: IP

Verbindungen alle Fehlerklassen untersuchen, bei LAN-Verkehr vielleicht nicht unbedingt.

16.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 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).

Kapitel 16 • TCP/IP – Die DoD-Protokolle

409

•

Jetzt wird das Protokollspektrum voll ausgereizt: Neben LLC-IPX-Broadcasts werden nun auch welche gesendet mit Ethernet-II-IPX, LLC-SNAP-IPX, 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) MircosoftRechner:

•

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 gespielt haben, dass hierdurch die Migration seitens der Kunden von NetWare-IPX-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 NetBIOSNamensauflö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 Microsoft-Rechner dabei beobachtet werden, Internet-Router, die ICMP-Meldungen aus fernen Ländern zurückgaben, für DNS-Server zu halten und um NetBIOS-Namensauflö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.

410

Im Fokus des Analyzers: TCP

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.

16.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.

Abb. 16.22: TCP Header im LANdecoder32 (davor: der IP Header)

Kapitel 16 • TCP/IP – Die DoD-Protokolle

411

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.

16.8.1 Das Prinzip der TCP Data Flow Control Die Grundgedanken, die TCP und seiner Art der Datenfluss-Steuerung zugrunde gelegt wurden, waren: •

Bi-direktionaler Datenaustausch Innerhalb einer TCP-Verbindung soll die Datenkommunikation bi-direktional möglich sein. Während nämlich Funktionen wie File Transfer nur uni-direktional 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.

412

Im Fokus des Analyzers: TCP

•

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 TCP-Teilnehmer 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 TCP-SYN = 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. 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 Start-Offset 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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

•

413

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-Pong-Methode 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. 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 Ping-PongSpiel: 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

414

Im Fokus des Analyzers: TCP

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 (TCP-PSH) 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.

Eine Übersicht hinsichtlich aller TCP-Paramter ist in Abschnitt 16.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).

Tab. 16.17: TCP Flags – Übersicht

Kapitel 16 • TCP/IP – Die DoD-Protokolle

415

Abk.

Funktion

Bedeutung

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).

Tab. 16.17: TCP Flags – Übersicht (Forts.)

Es soll ein TCP-Verbindungsaufbau gezeigt werden, weil er für den TCP-Mechanismus beispielhaft ist (Abbildung 16.23 ff.).

Abb. 16.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. 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.

416

Im Fokus des Analyzers: TCP

Dies wiederum bestätigt der Initiator mit TCP-ACK, SEQ Number 45607 und ACK Number 3090536427. Im Detail sieht das so aus:

Abb. 16.24: Die IP-Adressen der beiden TCP-Teilnehmer beim Verbindungsaufbau

Abb. 16.25: TCP-SYN (#2529) und TCP-SYN/ACK (#2530) beim Verbindungsaufbau

Kapitel 16 • TCP/IP – Die DoD-Protokolle

417

Abb. 16.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.

418

Im Fokus des Analyzers: TCP

Abb. 16.27: TCP Handshake mit Window Size & Maximum Segment Size

16.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.

Abb. 16.28: TCP Header mit »Source & Destination Port«, »Sequence & Acknowledge Number« und »Data Offset«

Kapitel 16 • TCP/IP – Die DoD-Protokolle

419

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

Tab. 16.18: Auswahl gängiger UDP/TCP-Ports

420

Im Fokus des Analyzers: TCP

Socket

Protocol

0138

NETBIOS-DGM – NETBIOS Datagram Service

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

Tab. 16.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 Port-Kennungen 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 Listing 16.20: WinNT Registry-Einträge zu UDP-TCP Sicherheitsfilter

Kapitel 16 • TCP/IP – Die DoD-Protokolle

421

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 Listing 16.21: WinNT Registry-Eintrag zur Begrenzung der TCP-Verbindungen

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 16.6.1.

Abb. 16.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 Listing 16.22: WinNT Registry-Eintrag zu verwendbaren Port-Nummern

422

Im Fokus des Analyzers: TCP

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 Listing 16.23: WinNT Registry-Eintrag zur Wartezeit zur Socket-Freigabe

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. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters\KeepAliveInterval HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters\KeepAliveTime Listing 16.24: WinNT Registry-Einträge zu TCP Keep-Alive

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 Listing 16.25: WinNT Registry-Einträge zu TCP Retransmissions

16.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 16.8.1.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

423

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.

Abb. 16.30: TCP Expertendiagnose (LANdecoder32)

In Abbildung 16.30 ist eine solche automatische Auswertung zu sehen: 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).

424

Im Fokus des Analyzers: TCP

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 16.31 zu sehen.

Abb. 16.31: TCP Retransmitted Packets – viele Wiederholungen

In Abbildung 16.31 wird sichtbar, dass sehr viele TCP-ReTx (Retransmissions) erkannt wurden. In Abbildung 16.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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

425

Abb. 16.32: TCP-Fehler (1): Rücksprung in der Sequence Number (#2268, #2269)

Die Tabelle 16.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

sendet

ab

SEQ=3.448.997

#2269

192.168.254.100

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

Tab. 16.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. 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.

426

Im Fokus des Analyzers: TCP

Abb. 16.33: TCP-Fehler (2): mehrfache Rücksprünge und Retransmissions

Die Tabelle 16.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

Tab. 16.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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

427

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; 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 16.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.

428

Im Fokus des Analyzers: TCP

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. 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.)

Kapitel 16 • TCP/IP – Die DoD-Protokolle

429

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 Listing 16.26: WinNT Registry-Eintrag zur Häufigkeit von TCP-Wiederholungen

16.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. Beispiel: Der Offset-Wert stimmt nicht Das folgende Beispiel zeigt, wie massiv sich hier Fehler auswirken können.

Abb. 16.34: X-Window – scheinbar jedenfalls

430

Im Fokus des Analyzers: TCP

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 16.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.

Abb. 16.35: TCP-Fehler: Der Längenwert in »Data Offset« stimmt nicht

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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

431

Dies ist ein schöner Beweis für die Tatsache, dass man um die Handarbeit letzten Endes nur bei wirklich simplen Fehlern herumkommt.

16.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 16.17 verwiesen.

Abb. 16.36: TCP Header mit Flags: FIN, SYN, RST, PSH, ACK, URG

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. Zu dem Fehler der AS/400 kam dann der zweite Fehler, dass die TCP- und TelnetTreiber 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ß.

432

Im Fokus des Analyzers: TCP

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.

Abb. 16.37: TCP-Fehler: Push Flag bei leerem Paket

In Abbildung 16.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 16.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 TCPSYN-Fluten unempfindlich machen soll.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

433

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 Listing 16.27: WinNT Registry-Einträge zu Versuchen des Verbindungsaufbaus

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. 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 16.8.6.

434

Im Fokus des Analyzers: TCP

Fehler: TCP-FIN und TCP-RST werden nicht beantwortet Es gehört zu den allgemeinen Erscheinungen von Internet Webservern, auf TCPFIN 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 Internet-Session 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 ... 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 Listing 16.28: WinNT Registry-Einträge zu TCP Keep-Alive

Kapitel 16 • TCP/IP – Die DoD-Protokolle

435

16.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.

Abb. 16.38: TCP-Header mit Window Size & Checksum

Zur Erinnerung (siehe 16.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. 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 Listing 16.29: WinNT Registry-Eintrag zur TCP Window Size

Fehler: TCP Window Size fällt auf Null Wenn die TCP Window Size auf Null fällt, ...

436

Im Fokus des Analyzers: TCP

•

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. 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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

•

437

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 Nicht-Ausschö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 UnixRechnern 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 •

praktisch auf jedes eingehende Paket ein TCP-ACK zu senden;

•

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 (!!); -

438

Im Fokus des Analyzers: TCP

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.

16.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 aufgenommen wurden (weil der Eingangspuffer des Analyzer zu klein eingestellt war), auch nicht auf die korrekte Prüfsumme hin untersuchen können.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

439

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.

16.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 Listing 16.30: WinNT Registry-Eintrag zum TCP Urgend Pointer

16.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.

440

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 Listing 16.31: WinNT Registry-Einträge zur Erkennung schlechter Router/Routen

Siehe auch zur IP-Fragmentierung die Abschnitte 16.7.3 (IP Total Length) ff.

16.8.10 TCP Expertendiagnose Bereits in Abschnitt 16.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.

Abb. 16.39: TCP Expertenanalyse: Definition von Schwellwerten zur Qualitätssicherung

Kapitel 16 • TCP/IP – Die DoD-Protokolle

441

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. Über Schwellwerte wie die hier in Abbildung 16.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.

16.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.

Abb. 16.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.

442

Im Fokus des Analyzers: UDP

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. 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 16.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 Microsoft-Fehler? ... 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:

Kapitel 16 • TCP/IP – Die DoD-Protokolle

443

Es können UDP-Ports auch gezielt außer Kraft gesetzt werden. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AdapterName#\ Parameters\Tcpip\UdpAllowedPorts Listing 16.32: WinNT Registry-Eintrag zum UDP Sicherheits-Filter

16.10 BOOTP/DHCP 16.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.

Abb. 16.41: BOOTP-Request eines IP-Clients

444

BOOTP/DHCP

In Abbildung 16.41 und 16.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 BOOTPServer 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.

Abb. 16.42: BOOTP-Reply des BOOTP-Servers an den IP-Client

Untypisch an der Antwort in Abbildung 16.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 16.43 zeigt. Es ist weiterhin zu sehen, dass BOOTP im letzten Bild zusätzliche Daten transportiert – hier handelt es sich um DHCP-Daten.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

445

Abb. 16.43: BOOTP-Dialog mit IP-Broadcast-Adressen

16.10.2 DHCP – Dynamic Host Configuration Protocol In Abbildung 16.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. 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 ZeitAngaben 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). Die DHCP-Daten in Abbildung 16.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:

446

BOOTP/DHCP

Abb. 16.44: Hex-Dump der DHCP-Daten in einem BOOTP-Reply DHCP Bytes

Code (dez.)

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

0x08

WINS Node Type = 8 = Hnode

0x2E01 0xFF

46

Länge (dez.)

1

Options-Wert (Hex-Bytes)

Bedeutung bzw. Inhalt der DHCP-Option

(Ende von DHCP)

Tab. 16.21: DHCP-Auflösung am Beispiel der Abbildung 16.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 DHCP-Clients 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!

Kapitel 16 • TCP/IP – Die DoD-Protokolle

447

Option hex

Option dez.

Länge

Konfiguierbar beim WinNT DHCP Server

Bedeutung

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

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

Tab. 16.22: DHCP Options

448

BOOTP/DHCP

Option hex

Option dez.

Länge

Konfiguierbar beim WinNT DHCP Server

Bedeutung

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

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

Tab. 16.22: DHCP Options (Forts.)

Kapitel 16 • TCP/IP – Die DoD-Protokolle

449

Option hex

Option dez.

Länge

Konfiguierbar beim WinNT DHCP Server

Bedeutung

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

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)

Tab. 16.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 sind bitte dem Windows-Kapitel 20 zu entnehmen. Ansonsten ist zu verweisen auf: Microsoft Windows NT Server Version 4 – Die technische Referenz (Microsoft Press 1998) , S. 473 ff.

450

SNMP/RMON

16.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

16.11.1 SNMP: Befehls- und Abfragesprache SNMP ist eine Befehls- und Abfragesprache, die ursprünglich zur Überwachung von Routern entwickelt wurde. 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:

16.11.2 SNMP-over-IPX Bereits im vorigen Abschnitt 16.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.

16.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.

Kapitel 16 • TCP/IP – Die DoD-Protokolle

451

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.

16.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. 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.

16.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.

452

SNMP/RMON

16.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«

16.11.7 Messtechnik im Bereich von TCP/IP Es sei auf das Kapitel 3 »Grundlagen der Methodik« verwiesen. Hier wird auf die Stärken und Schwächen der Fernanalyse via SNMP und RMON hinreichend eingegangen. Weiterhin wird empfohlen, die beiden Kapitel 18 »TCP/IP Diagnose-Tools« und 22 »Windows Tools« zu lesen. Beide enthalten Beschreibungen von Hilfsprogrammen sowie genaue Anleitungen, wie mit diesen Hilfsmitteln im Fehlerfalle vorzugehen ist.

Kapitel 17 TCP/IP – Unix /etc 17.1 17.2 17.3 17.4 17.5 17.6 17.7 17.8 17.9 17.10 17.11

/etc/passwd /etc/shadow /etc/group /etc/hosts /etc/hosts.equiv /etc/networks /etc/gateways /etc/protocols /etc/services /etc/exports /etc/ftpusers

455 456 456 457 458 459 459 460 461 462 464

454

Die Protokolle der TCP/IP-Familie wurden wesentlich unter UNIX und auf Ethernet entwickelt. Die wichtigsten Konfigurationsdateien aus dem bekannten Festplattenverzeichnis /etc sollen darum hier kurz vorgestellt werden. /etc

Dieses von Unix her typische Verzeichnis wurde auch auf NetWare-Servern übernommen sowie bei WinNT: winnt\system32\drivers\etc

Einige der im nächsten Kapitel »TCP/IP Diagnose-Tools« vorgestellten Werkzeuge greifen auf Angaben dieser Dateien zurück; dies gilt ganz wesentlich für NFS, da der Authentisierungs-Mechanismus des Network File System u.a. auf den Angaben der Unix-Benutzer-Datenbank beruht. Im Folgenden werden besprochen: Datei

Bedeutung

/etc/passwd

Benutzer-Datenbank, in älteren Unix-Versionen auch mit Passwörtern

/etc/shadow

Enthält ab Unix SVR4v4 die aus passwd ausgelagerten Passwörter

/etc/group

Gruppen-Datenbank

/etc/hosts

Alias-Namen für IP-Host-Adressen

/etc/ hosts.equiv

Nennt rlogin-Benutzer, die ohne Passwort zugreifen dürfen

/etc/networks

Alias-Namen für IP-(Sub-)Netzwerkadressen

/etc/gateways

Angabe statischer Routen (korrespondiert mit Befehl route add)

/etc/protocols

IDs der von IP übertragenen Protokolle

/etc/services

IDs der von UDP-TCP übertragenen Protokolle (Ports/Sockets)

/etc/exports

Tabelle der Datei- und Verzeichnisfreigaben via NFS

/etc/exportfs

Befehl zur Erneuerung der Freigaben gemäß /etc/exports

/etc/xtab

Tabelle mit den aktuell exportierten Dateisystemen (Freigaben)

/etc/ftpusers

Tabelle der nicht zugelassenen FTP-Benutzer

Tab. 17.1: Traditionelle Systemdateien unter Unix im Verzeichnis /etc

Kapitel 17 • TCP/IP – Unix /etc

17.1

455

/etc/passwd Die Datei /etc/passwd enthält: •

Benutzer-Namen

•

Passwort

•

User ID

•

Group ID

•

Kommentar

•

Login-Verzeichnis

•

Login-Shell

Passworte liegen ab SVR4v4 in /etc/shadow; dann enthält /etc/passwd nur einen Platzhalter an Stelle des Passwortes.

17.1.1 Achtung! NFS UIDs (User IDs) sollten netzwerkweit eindeutig sein; hierfür sollten Datein wie / etc/passwd zentral auf einem NIS-Server geführt werden. Grund ist der Umstand, dass NFS die Benutzer-Authentisierung nur über UID prüft; und wenn einzelne UIDs auf verschiedenen UNIX-Hosts mehrfach vorkommen, kann über eine einzele UID nicht mehr zwingend auf nur einen Anwender geschlossen werden, da die Benutzerkennung nicht mehr eindeutig wäre. Beispiel: root:mrXnfjjpypoX.,..YI:0:1:Superuser:/: daemon:*,..:1:1:System daemons:/etc: bin:*,..:2:2:Owner of system commands:/bin: sys:*,..:3:3:Owner of system files:/usr/sys: adm:*,..:4:4:System accounting:/usr/adm: uucp:*,..:5:5:UUCP administrator:/usr/lib/uucp: auth:*,..:7:21:Authentication administrator:/tcb/files/auth: asg:*LK**,..:8:8:Assignable devices:/usr/tmp: cron:*,..:9:16:Cron daemon:/usr/spool/cron: sysinfo:*,..:11:11:System information:/usr/bin: dos:*,..:16:11:DOS device:/tmp: mmdf:*,..:17:22:MMDF administrator:/usr/mmdf: network:*,..:18:10:MICNET administrator:/usr/network: nouser:*:28:28:Network user w/o privileges:/:/bin/false Listing 17.1: Beispiel für die Unix-Datei /etc/passwd

456

/etc/shadow

listen:*:37:4:Network daemons:/usr/net/nls: lp:*,..:71:18:Printer administrator:/usr/spool/lp: audit:*,..:79:17:Audit administrator:/tcb/files/audit: ingres:*,..3E:777:50:Database administrator:/usr/ingres: games:*,..CI:42:50:Games Admin:/usr/games:/bin/rsh synapse:IrFHuHtKHuHMI,..GI:0:1:F.Walther:/usr/synapse:/bin/sh user01:ldLe6zz1OdHVI,..XI:200:50:USR 01:/usr/user01:/bin/sh Listing 17.1: Beispiel für die Unix-Datei /etc/passwd

Die UIDs bis einschließlich 199 bezeichnen Systemprozesse, die Unix-intern als Benutzer geführt werden, damit sie Zugriff auf ihre Systemdateien erhalten. Ab UID=200 folgen »echte Anwender«.

17.1.2 Achtung! UID=0 Benutzer mit der UID=0 sind root user und damit Systemverwalter mit allen Rechten. Die UID=0 ist ab Installation von Unix nur dem Benutzer root vorbehalten. Hier wurde ein weiterer Benutzername, nämlich synapse, mit der UID=0 ausgestattet, um bei Verlust des Passwortes von root ein Login als Systemverwalter weiterhin zu ermöglichen. Diese Vorgehensweise ist praktisch, aber nicht unkritisch – man muss wissen, was man da tut.

17.2

/etc/shadow Auf den aktuellen Unix-Systemen enthält nicht mehr die älteren Datei /etc/ passwd die Passworte, da jeder Benutzer auch mit den geringsten Zugriffsrechten die Datei /etc/passwd lesen kann. Der Umstand, dass die Passworte auch in /etc/ passwd immer schon verschlüsselt waren, konnte keine hinreichende Beruhigung sein. Auf die Datei /etc/shadow haben Anwender keinen direkten Lese- oder Schreibzugriff mehr.

17.3

/etc/group Die Datei /etc/group enthält: •

Gruppen-Namen

•

Group ID

•

Group Members.

Kapitel 17 • TCP/IP – Unix /etc

457

Beispiel: root::0: other::1:root,daemon,user02 bin::2:bin,daemon sys::3:bin,sys,adm adm::4:adm,daemon,listen uucp::5:uucp,nuucp mail::7: asg::8:asg network::10:network sysinfo::11:sysinfo,dos daemon::12:daemon terminal::15: cron::16:cron audit::17:audit lp::18:lp backup::19: mem::20: auth::21:auth mmdf::22:mmdf sysadmin::23:synapse nogroup::28:nouser group::50:ingres,synapse,user01,user02 seminar:*:100:gast,superman Listing 17.2: Beispiel für die Unix-Datei /etc/group

Die GIDs (Group IDs) bis einschließlich 49 nennen Systemgruppen; ab GID=50 folgen Benutzergruppen.

17.3.1 Achtung! NFS Es gelten die Hinweise aus Abschnitt 17.1.1 entsprechend.

17.4

/etc/hosts Die Datei /etc/hosts enthält: •

IP-Adresse

•

Host Alias-Name(n)

•

Kommentar(e)

458

/etc/hosts.equiv

Wird von Internetapplikationen wie E-Mail, Ping etc. ausgewertet. Der AliasName hat nur lokale Bedeutung, sollte aber netzwerkweit eindeutig sein (NIS). Beispiel: 127.0.0.1 128.127.1.1 128.127.1.2 128.127.1.3 128.127.1.4 128.127.1.100 128.127.50.9

localhost synapse1 synapse2 synapse3 synapse4 syn-server-311 syn311 syn-311 # Alle Namen ok user09

Listing 17.3: Beispiel für die Unix-Datei /etc/hosts

Seit der weiten Verbreitung von DNS ist es unüblich geworden, Rechnernamen auf jedem IP-Rechner lokal zu führen. Wenn jeder IP-Teilnehmer auf dem DNSServer einen eindeutigen Namen hat und Suchmaschinen die Suche nach Rechnern und Ressourcen unterstützen, ist dies der statischen Datei /etc/hosts vorzuziehen.

17.4.1 Achtung: Local Host Die IP-Adresse 127.0.0.1 bezeichnet das lokale System zu Testzwecken und darf nicht im Netzwerk selber verwendet werden!

17.5

/etc/hosts.equiv Die Datei /etc/hosts.equiv (user equivalence) enthält: •

Machine Name(s)

•

Rlogin User Name(s)

Die Datei enthält die Namen von Benutzern, denen der Zugriff via rlogin erlaubt werden soll, ohne dass ein Passwort abgefragt wird, da sie als equivalent zu einem Benutzereintrag auf dem jeweils anderen Host angesehen werden. /etc/ hosts.equiv greift auf /etc/hosts zurück. Der rshd (Remote Shell Daemon) muss laufen. Statt /etc/hosts.equiv kann auch im Benutzer-Home-Verzeichnis .rhosts verwendet werden; das wäre jedoch aufwendiger, da nicht zentral verwaltbar. Die Einträge enthalten: remote_machine_name/remote_user_name. /etc/passwd muss den Namen und die UID jedes remote users aufweisen.

Kapitel 17 • TCP/IP – Unix /etc

459

Beispiel: host1 user_shiva host_linux user_somebody Listing 17.4: Beispiel für die Unix-Datei /etc/hosts.equiv

17.6

/etc/networks Die Datei /etc/networks enthält: •

Alias-Name für IP (Sub-) Netzwerke

•

IP Netzwerkadresse

Beispiel: loopback 127 sco 132.147 sco-hq 132.147.128 sco-mfg 132.147.64 sco-engr 132.147.192 sco-slip 132.147.32 sco-tcplab 132.147.160 sco-odtlab 132.147.1 Listing 17.5: Beispiel für die Unix-Datei /etc/networks

Diese Einträge sind einem Rechner mit SCO-Unix entnommen: Der Hersteller gibt also seine eigenen Subnet-Alias-Namen an.

17.7

/etc/gateways Die Datei /etc/gateways enthält: Anweisungen an routed (Route Daemon) oder gated (Gateway Daemon), bestimmte static routes zu erzeugen: Beispiel: # List of unusual routes which must be added to the routing # database statically. # Syntax: Listing 17.6: Beispiel für die Unix-Datei /etc/gateways

460

/etc/protocols

# net/host [destin addr.] gateway [next router] # [metric] [act./pass.] net arpa gateway sj-in1 passive # to arpanet; # sj-in1 is passive. host 130.57.6.40 gateway 192.67.172.55 # route with numbers. Listing 17.6: Beispiel für die Unix-Datei /etc/gateways (Forts.)

Die Datei /etc/gateways wird heute kaum noch genutzt, da Router heutzutage in der Hardware arbeiten und nicht mehr als Software-Prozess auf Unix-Rechnern.

17.7.1 Achtung! route add Der Zweck, statische Routen einzurichten, kann auch dynamisch mit dem Kommando route add erreicht werden. Dieser Befehl ist auch auf WinNT-Maschinen verfügbar.

17.7.2 Achtung! Redundanz vs Sicherheit Statische Routen haben den Vorzug, dass der Weg durchs Netzwerk vorgeschrieben ist – sei es, dass dies zur Entlastung anderer Strecken gewünscht wird, sei es, dass dies aus Sicherheitsgründen gewollt ist; Sicherheit ist hier gemeint als Vertraulichkeit der Daten. Eine Ausfall-Sicherheit im Sinne von Wege-Redundanz ist dagegen mit statischen Routen unmöglich.

17.8

/etc/protocols Die Datei /etc/protocols enthält die Kennungen der von IP übertragenen Protokolle: •

Protokollnamen

•

Protokollkennung unter IP

Beispiel: # Internet (IP) protocols ip 0 IP # internet protocol, pseudo no. icmp 1 ICMP # internet control message protocol ggp 3 GGP # gateway-gateway protocol tcp 6 TCP # transmission control protocol Listing 17.7: Beispiel für die Unix-Datei /etc/protocols

Kapitel 17 • TCP/IP – Unix /etc

egp 8 EGP pup 12 PUP udp 17 UDP hello 63 HELLO

# # # #

461

Exterior-Gateway Protocol PARC universal packet protocol user datagram protocol HELLO Routing Protocol

Listing 17.7: Beispiel für die Unix-Datei /etc/protocols (Forts.)

Warnung Nicht anfassen! Die Protokollkennungen sollten nicht verändert werden!

17.9

/etc/services Die Datei /etc/services enthält die Kennungen der von UDP-TCP übertragenen Protokolle bzw. Dienste; diese Kennungen werden Sockets oder Ports genannt. •

Protokollname

•

Protokoll-Port (verwendet von TCP und UPD).

Die Ports bis 512 sind allgemein verwendete Ports von Internetdiensten (WellKnown Ports), die Ports bis 1.024 sind Unix-typisch. Oberhalb von 1.024 beginnt der frei verfügbare Port-Bereich; er endet überlicher Weise bei 5.000. Beispiel (gekürzt): # # Network services, Internet style # echo 7/tcp echo 7/udp daytime 13/tcp daytime 13/udp netstat 15/tcp qotd 17/tcp quote chargen 19/tcp ttytst source chargen 19/udp ttytst source ftp 21/tcp telnet 23/tcp smtp 25/tcp mail # # UNIX specific services Listing 17.8: Beispiel für die Unix-Datei /etc/services

462

/etc/exports

# exec login who route timed uucp

512/tcp 513/tcp 513/udp 520/udp 525/udp 540/tcp

whod router routed # 521 also timeserver uucpd # uucp daemon

Listing 17.8: Beispiel für die Unix-Datei /etc/services (Forts.)

Eine lange Liste der Ports ist auf der CD-ROM zum Buch zu finden.

17.9.1 Achtung! Nicht anfassen! Die Protokollkennungen sollten nicht verändert werden!

17.10 /etc/exports Die Datei /etc/exports enthält: Pfad/Name genau der Verzeichnisse, die nach außen für den Zugriff durch NFS-Clients freigegeben werden sollen. Der NFSDaemon muss laufen. Beispiel: /usr/common /usr/programs Listing 17.9: Beispiel für die Unix-Datei /etc/exports (1)

Grundsätzlich lautet die Syntax: directory -option[,option ]...

... wobei directory das freizugebende Verzeichnis nennt und -option den Parameter. Option

Bedeutung

-ro

Verzeichnis ist »read-only«; falls nicht gesetzt, gilt »read-write«.

-rw=hostnames[:hostname]...

Verzeichnis ist »read-only« für alle, sofern sie nicht hier extra aufgeführt sind. Ist »rw=..« nicht gesetzt, gilt »rw« für alle.

Tab. 17.2: Optionen beim Export von Dateisystemen/Verzeichnissen

Kapitel 17 • TCP/IP – Unix /etc

463

Option

Bedeutung

-anon=uid

Anrufer, deren UID nicht bekannt ist bzw. nicht auf eine bekannte UID gemappt werden kann, werden auf die hier angegebene UID gesetzt. »root«-User (UID=0) werden immer als »anonym« angesehen, es sei denn, dass die Option »root« (s.u.) gesetzt ist unter Angabe des »root«-Users. Default: UID von User »nobody«. Ist »nobody« nicht gegeben, wird der Wert auf 65534 gesetzt (-1).

-anon=65535

Deaktiviert die Option.

-root=hostnames[:hostname]...

Gewährt »Root«-Usern der hier aufgeführten IPHosts auch auf dem Gastrechner die Root-Rechte. Default: Niemand hat Root-Rechte.

-access=client[:client]...

Gewährt Mount-Zugriff an alle Clients, die hier aufgeführt sind. Angegeben werden Host-Namen (/etc/ hosts). Sofern nicht gesetzt: Jeder hat Zugriff auf das Exportverzeichnis, sofern diese Option nicht gesetzt ist.

-secure

Verlangt sichereres Übertragungsprotokoll, als gerade vom Client beim Zugriff verwendet.

Tab. 17.2: Optionen beim Export von Dateisystemen/Verzeichnissen (Forts.)

Beispiel: /usr/share -anon=200 /usr/textfiles -anon=200 Listing 17.10: Beispiel für die Unix-Datei /etc/exports (2)

Hier werden alle unbekannte NFS-Benutzer mit den Rechten des lokalen Anwenders mit der UID=200 ausgestattet. Beispiel: /usr -access=clients # export to my clients /usr/local # export to the world /usr2 -access=hermes:zip:tutorial # export to only these machines /usr/sun -root=hermes:zip # give root access only to these /usr/new -anon=0 # give all machines root access Listing 17.11: Beispiel für die Unix-Datei /etc/exports (3)

464

/etc/ftpusers

/usr/bin -ro # export read-only to everyone /usr/stuff -access=zip,anon=-3,ro Listing 17.11: Beispiel für die Unix-Datei /etc/exports (3) (Forts.)

17.10.1 Achtung! -anon=0 Es ist gefährlich, leichtfertig unbekannten NFS-Benutzern im Freigabeverzeichnis die vollen Admin-Rechte zu geben, indem mit der Option -anon=0 die Rechte des Verwalters root gegeben werden.

17.10.2 /etc/exportfs Die Datei /etc/exportfs (export file system) ist ein ausführbares Programm; es liest die Datei /etc/exports aus und exportiert die angegebenen Verzeichnisse.

17.10.3 /etc/xtab Die Datei /etc/xtab (exports table) enthält: Pfad/Namen aller Verzeichnisse, die via NFS aktuell exportiert sind (z.B. nach Aufruf von /etc/exportfs).

17.11 /etc/ftpusers Die Datei /etc/ftpusers enthält: Die Namen der nicht zugelassenen FTP-Benutzer. Der FTP-Server-Daemon muss laufen. Es wird immer ein Benutzer je Zeile angegeben. Beispiel: shiva groucho-marx Listing 17.12: Beispiel für die Unix-Datei /etc/ftpusers

Kapitel 18 TCP/IP Diagnose-Tools 18.1 18.2 18.3 18.4

Unix-Kommandos TCP/IP Diagnose-Tools für Windows (Freundlicher) Angriff auf eine Website Hacker-Tools

466 472 490 504

466

Unix-Kommandos

Dieses Kapitel bespricht: •

die traditionellen Unix-Kommandos zur Netzwerkdiagnose (teilweise auch auf WinNT vorhanden – mit dem »Resoruce Kit für Windows NT4.0« ),

•

aber auch das aktuelle TCP/IP Diagnose-Tools für Windows (aber nicht von Microsoft), die letztlich aus diesen Unix-Kommandos hervorgegangen sind.

Zu den Windows-Programmen gehören AnySpeed (PY Software, USA/Shareware) und »What’s Up Gold« (Ipswitch, USA), die zusammen eine breite Palette der Diagnosefunktionen bieten. Es muss an dieser Stelle auf das Kapitel »Windows Tools« verwiesen werden, das die Hilfsprogramme von Microsoft vorstellt. Es enthält nicht nur Beschreibungen dieser Werkzeuge, sondern teilweise auch genaue Anleitungen zur Fehlererkennung im Netzwerk unter Einsatz dieser Mittel.

18.1

Unix-Kommandos Die wichtigsten Unix-Kommandos sind: Kommando

Zweck

arp

Anzeigen der Einträge der ARP-Tabelle (ARP Cache)

finger

Abfragen aktiver Benutzer auf fernen Rechnern

ipconfig

Gibt die Konfiguration des TCP/IP-Treibers aus

lpq/lpstat

Abfragen von Druckerwarteschlagen

netstat

Gibt Auskunft über aktuelle Netzwerkverbindungen

ping

Prüfen, ob ein IP-Rechner erreichbar ist

route

Ausgabe oder Änderung der Routing-Tabelle

snmp

Starten/Stoppen des SNMP Daemons

traceroute

TraceRoute – ausführlichere Routen-Prüfung als bei Ping

Tab. 18.1: Dienstprogramme bei Unix zu TCP/IP

18.1.1 arp Das Kommando arp bewirkt: Auskunft über die aktuelle ARP-Tabelle des IP-Hosts. Die ARP-Tabelle wird vom Address Resolution Protocol angelegt und enthält die Gegenüberstellung von IP-Adressen zu MAC-Adressen.

Kapitel 18 • TCP/IP Diagnose-Tools

467

Klagt ein Anwender darüber, keine Verbindung zu einem Host zu erhalten, kann ein Blick in die ARP-Tabelle zeigen, ob die Verbindung physikalisch auf MACEbene bereits zustande gekommen war oder nicht. Beispiele: arp -a

Zeigt alle aktuellen ARP-Einträge an. arp -d [IP_address]

Löscht den Eintrag der angegebenen IP-Adresse. arp -s IP_address MAC_address

Fügt einen neuen Eintrag hinzu.

18.1.2 finger Das Kommando finger bewirkt: Auskunft über (einen/alle) Benutzer auf einem fernen Rechner, sofern dieser den Finger-Dienst gestartet hat. Beispiel: finger [-l] [Benutzer@]HostName

Das Argument -l bewirkt eine lange Listenausgabe. Wird kein Benutzername angegeben, wird eine Antwort über alle Benutzer des fernen Rechners zurückgegeben (Sicherheit!). Der Host-Name kann auch die IP-Adresse des fernen Rechners sein.

18.1.3 ipconfig Das Kommando ipconfig bewirkt: Auskunft über die aktuelle TCP/IP-Konfiguration. Beispiel: ipconfig [-all]

468

Unix-Kommandos

Das Argument »-all« bewirkt die Ausgabe aller Angaben. Die Verwendung von ipconfig kann von System zu System unterschiedlich sein.

18.1.4 lpq/lpstat Die Kommandos lpq/lpstat bewirken: Auskunft über den Zustand von Druckwarteschlangen, auch über Systemgrenzen hinweg (also auch über das Netzwerk hinweg). Beispiel: lpstat -p [printerqueue]

Das Argument »-p« lenkt die Abfrage auf eine bestimmte Warteschlange.

18.1.5 netstat Das Kommando netstat bewirkt: Auskunft über die zurzeit aktiven Netzwerkverbindungen. Beispiele: netstat -a

Auskunft über die aktiven Internetverbindungen. netstat -i

Auskunft über die Netzwerkschnittstellen (interfaces). netstat -r

Auskunft über Routing Tables des Unix-Hosts. netstat -s

Statistiken über die Protokolle IP, ICMP, TCP. netstat -e

Kapitel 18 • TCP/IP Diagnose-Tools

469

Statistiken über Ethernet (nicht in allen Implementationen). netstat -p [protocol]

Statistiken über das angegebene Protokoll (nicht in allen Implementationen).

18.1.6 ping Das Kommando ping bewirkt: Aussendung eines IP-Paketes mit »ICMP: Echo Request« an einen bestimmten IP-Host; dieser muss mit »ICMP: Echo Reply« antworten. Grundsätzliche Syntax: ping 128.127.1.3

Ruft die angegebene Adresse. Gegebenenfalls wird im Hintergrund zunächst ein ARP-Ruf durchgeführt, um die MAC-Adresse des gewünschten IP-Hosts oder die MAC-Adresse des zuständigen Routers zu erhalten. Ping arbeitet meistens mit einer Vielzahl von Argumenten; diese können von Implementation zu Implementation variieren. Die jeweils unterstützten PingArgumente (Parameter) sollten an jedem System darum jeweils abgefragt bzw. nachgeschlagen werden. Üblich sind: Beispiele: ping -n100 128.127.1.3

Das Argument »-n« gibt an, wie oft gerufen werden soll (beliebige Zahlen möglich; hier: 100 Mal). ping -t 128.127.1.3

Das Argument »-t« lässt endlos rufen, bis Ping vom Anwender »t«erminiert wird. ping -l512 128.127.1.3

Das Argument »-l« gibt die »L«änge der ICMP-Pakete an. Der Vorgabewert beträgt 64 Bytes. Der max. Wert liegt bei 8.192 Bytes.

470

Unix-Kommandos

Warnung Falle! Es ist unbedingt wichtig, mit wechselnden Paketgrößen zu testen, bei Ethernet bis hinauf zu 1.518 Byte, da Paketverluste durch Fehler beim IP Fragmenting nicht bei der kleinen Paketgröße von 64 Byte erkannt werden! Wer immer nur Standard-Pings mit 64 Bytes absendet, wird sich immer wieder wundern, warum ein ferner Host antwortet, die Applikationssitzungen aber trotzdem immer wieder abstürzen. ping -R 128.127.1.3

Das Argument »-R« lässt Ping mit IP Record Route arbeiten; das heißt: Der genaue Vermittlungsweg wird in den Antworten der Gegenstelle festgehalten und kann ausgelesen werden. Damit lassen sich die überquerten Router erkennen. Warnung TraceRoute! Diese Funktion wird auch von TraceRoute erfüllt. Der Mechanismus von IP Record Route hat den Nachteil, dass nicht alle Protokoll-Implementationen diese Variante untersützen; auch Internetrouter nehmen es hier nicht so genau. Das Verfahren von TraceRoute dagegen ist grundsätzlich anders, da es über ICMP-Rückmeldungen der Router arbeitet: Es provoziert seitens der Router ICMP-Fehlermeldungen, die dann über reversive DNS-Abfragen in die RouterNamen umgesetzt werden können. Es wird auf das Kapitel »Windows Tools« verwiesen; das Windows-Ping bietet herausragende Möglichkeiten zur Diagnose.

18.1.7 route [add {..} {..} ] Das Programm route bewirkt: Das Anlegen eines neuen Eintrages in die Routing-Tabelle von routed (Route Daemon), sofern mit statischen Routen gearbeitet wird. Syntax: route add {destination_ip_net} {router_ip_address} [metric] route add {destination_ip_host} {router_ip_address} [metric]

Kapitel 18 • TCP/IP Diagnose-Tools

471

Das liest sich wie folgt: Für die Versendung von IP-Paketen ins angegebene IPZielnetz ist über den angegebenen IP-Router (gateway) zu gehen. Metric bezieht sich auf die Wegekosten (hop count) bis zum Ziel und bezieht sich auf den TTL-Parameter. route -f

Löscht alle Einträge. Warnung Falle! Statische Routen verfügen über weniger oder keine Ausfallsicherheit bei Wegfall eines Routers oder einer Leitung. Sie sind daher durchaus problematisch.

18.1.8 snmp start|stop Das Shell-Script-Kommando snmp start|stop (oder ähnlich) bewirkt auf UnixRechnern das Starten eines SNMP-Agenten, über den der Unix-Host via SNMP erreichbar und abfragbar ist. Die Syntax kann je Unix-Maschine unterschiedlich sein.

18.1.9 traceroute (WinNT: tracert) Das Kommando traceroute bewirkt die Ausgabe einer Liste aller Router, die zu einem fernen Host überquert werden. •

Ältere Varianten verwenden den Mechanismus IP Record Route, der nicht von allen Protokolltreibern und/oder Routern unterstützt wird (wurde).

•

Neue Varianten arbeiten über das Hochzählen von IP-TTL sowie mit den ICMP-Rückgaben der Router, ggf. noch mit DNS zur Namensauflösung.

Die TTL-Technik von traceroute arbeitet so: Es wird begonnen mit TTL=1, heißt: Die IP-Pakete enthalten den TTL-Wert 1; da der Wert von Time-to-Live das Maximum der erlaubten Hops angibt (und darum einen Hop Credit darstellt), können Pakete mit TTL=1 keinen Router überqueren: der erste Router vermindert das TTL, und somit fällt es auf TTL=0. In der Folge wird das IP-Paket verworfen und der Router gibt eine ICMP-Meldung zurück: »ICMP: Time Exceeded«.

472

TCP/IP Diagnose-Tools für Windows

Nach und nach wird dann der TTL-Wert um jeweils 1 erhöht; von jedem TTLWert werden ggf. zwei oder drei Pakete verschickt. Dadurch kommen die IPPakete jeweils immer einen Router weiter; so kommen nach und nach ICMPRückgaben aller Router im IP-Weg zurück. Sollte eine Verbindungsaufnahme aus einer Anwendung heraus an zu niedrigem Vorgabe-TTL-Wert gescheitert sein, wird traceroute am Ende zeigen, wie hoch der TTL-Wert zu einem bestimmten Empfänger mindestens sein muss, da traceroute beim Erreichen der Gegenstelle die Zahl der Router-Hops anzeigt. Beispiel: traceroute 145.23.35.2

Da teilweise auch IP Source Routing unterstützt wird, ist hierzu die jeweilige Implementation auf die entsprechenen Parameter hin abzufragen.

18.2

TCP/IP Diagnose-Tools für Windows Es gibt drei Standardaussagen von Benutzern: •

»Ich kann meinen Server (Drucker, Router) nicht finden.«

•

»Das Netzwerk ist langsam.«

•

»Ich habe mein Passwort vergessen.«

Am Passwort bzw. an der Vergesslichkeit werden wir nichts ändern können, und messen werden wir sie auch nicht. Aber die Aussagen, eine Ressource könne nicht gefunden werden, das Netzwerk sei langsam, sollten schnell und simpel überprüft werden können.

18.2.1 Großes Netzwerkmanagement Hierzu gibt es die »großen« Werkzeuge des Netzwerkmanagements, die alles und jeden überwachen und wen-auch-immer benachrichtigen, wenn etwas passiert. Oft aber liegen diese Managementsysteme brach, weil sie wegen ihres Umfangs nie richtig konfiguriert wurden. Oder Mitarbeiter des User Help Desks haben keinen Zugriff darauf, brauchen aber eigene Daten über den Zustand des Netzes und der Kommunikationsbeziehungen darin. Dann helfen kleine Tools.

Kapitel 18 • TCP/IP Diagnose-Tools

473

18.2.2 Kleine Netzwerk-Tools Einige kleine Werkzeuge werden schon mit Win95/98 und WinNT ausgeliefert; sie werden in den Windows-Kapiteln kurz beschrieben. Es gibt jedoch auch viele kleine Programme von Drittherstellern – Software, die nicht viel Geld kostet, aber schnelle und deutungsfähige Daten liefern. Zwei Programme, die sich in der Arbeit des Autors bewährt haben, sollen hier vorgestellt werden: »AnySpeed« (PY Software) und »What’s Up Gold« (Ipswitch). Es sollen aber noch einige andere Tools genannt werden, die als Freeware, Shareware oder doch kostengünstige Software im Internet bezogen werden können. Shareware-Tool

Internet Homepage

4Net

http://www.cartoonlogic.com/4net/

Any Speed

http://www.pysoftware.com/

Big Brother

http://maclawran.ca/sean/bb-dnld/index.html

Free Wizard

http://www.freewizard.de/

GeoBoy

http://www.ndg.com.au/products/gb/main.shtml

IDyle GimmIP

http://www.idyle.com/gimmip/

Internet Anywhere Toolkit

http://www.pcpro.de/download/library/00I80-wf.htm

Internet Maniac

http://www.pcdirekt.de/download/library/00PJV-wf.htm

IP Network Browser

http://SolarWinds.net/

IP Sentry

http://www.ipsentry.com/

IP Subnet Calculator

http://www.net3group.com/

Look@Me

http://www.farallon.com/

NeoTrace

http://www.neoworx.com/

NetSense u.a.

http://www.net3group.com/

NetCat

http://www.l0pht.com/~weld/netcat/

NetoScope

http://www.basta.com/ProdNetoscope.htm

Netscan Tools

http://www.nwpsw.com – http://www.netscantools.com/

Ping Plotter

http://www.nessoft.com/pingplotter/

PortFlash

http://www.webroot.com/

Recon-1 Lte

http://www.peakcom.com/recon-1/index.htm

Remote Logout

http://www.hostus.com/

Remotely Possible

http://www.avalan.com/

Tab. 18.2: Shareware-Tools für TCP/IP bzw. Internet

474

TCP/IP Diagnose-Tools für Windows

Shareware-Tool

Internet Homepage

Servers Alive?

http://www.woodstone.nu/salive/

SniffIt

http://reptile.rug.ac.be/~coder/sniffit/sniffit.html

Subnet Wiz

http://tucows.cableinet.net/

Visual Route

http://www.visualroute.com/ Download-Seiten (zwei von vielen vielen):

WinNT Tools

http://www.datacomm.ch/tucows/toolnt.html

Win95 Tools

http://www.datacomm.ch/tucows/tool95.html

Tab. 18.2: Shareware-Tools für TCP/IP bzw. Internet (Forts.)

Von einer Bewertung der Shareware-Tools soll hier abgesehen werden. Es sei verwiesen auf das Kapitel »Hersteller und Produkte«, das kurze Angaben zu den Produkten enthält.

18.2.3 AnySpeed (PY Software, USA) http://www.pysoftware.com/

Ist das Netzwerk langsam? Was ist das überhaupt: ein langsames Netzwerk? Die Antwort lautet: Es ist ein Missverständnis. Was Anwender meinen, ist: »Die Antwortzeiten sind zu lang.« Das wäre eine nachvollziehbare Aussage – und sie lässt offen, woran es liegt, denn das kann der Anwender beim besten Willen nicht beurteilen. Oft aber ist auch diese Aussage problematisch: Denn manchmal sind die Zugriffe über das Netzwerk nicht langsamer als sonst auch, aber das Zeitempfinden des Anwenders hat sich geändert; vielleicht, weil er heute ungeduldig ist (und sonst nicht). Das kleine Programm AnySpeed prüft die Antwortzeiten zwischen dem AnySpeed-Rechner und •

Netzwerklaufwerken (Schreib/Lese-Test)

•

CD-ROM-Server

•

IP-Rechnern, identifiziert mit IP-Adresse oder DNS-Name

Es können folgende Schwellwerte und Aktionen für die Pings zu den angegebenen Netzwerk-Ressourcen festgelegt werden: •

Abstand der Pings in Millisekunden

•

Timeout (bei fehlender Antwort) in Millisekunden

Kapitel 18 • TCP/IP Diagnose-Tools

•

Aktion (z.B. Mail) bei Unterschreitung eines bestimmten Durchsatzes

•

Aktion (z.B. Mail) bei Überschreitung eines bestimmten Durchsatzes

•

Getrennte Farben für einzelne Netzwerk-Ressourcen

475

Die Darstellung der Ping-Antwortzeiten erfolgt in drei verschiedenen Varianten: 1. Tabelle mit Ressourcen-Name und der Angabe des Datendurchsatzes (in Kbps) – bei Schreib-Operationen (nur Netzwerk-Laufwerke) – bei Lese-Operationen (nur Netzwerk-Laufwerke) – bei Pings (Internet- bzw. IP-Ressourcen) 2. Grafik mit je einer Kurve pro Ressource – Skala: 60 Minunten 3. Grafik mit je einer Kurve pro Ressource – Skala: 24 Stunden Die nicht eben luxuriöse grafische Auflösung reicht völlig aus, um den Verlauf des Durchsatzes und der Durchsatz-Schwankungen zu erkennen, zumal die Skala jeweils vergrößert und verkleinert werden kann. Entweder läuft AnySpeed im Hintergrund, oder es ist jederzeit im Vordergrund – ungeachtet anderer Applikationen, mit denen gearbeitet wird. So ist es möglich, unauffällig die Übersicht zu behalten (Abbildung 18.1).

Abb. 18.1: AnySpeed mit kleinster Darstellung (60-Minuten-Fenster)

Während das 60-Minten-Fenster immer nur das Minuten-Mittel zeigt, enthält die Tabellendarstellung den aktuellen Wert bzw. Status; so wird durchaus angezeigt »Timeout« oder »No Connection«. Die langfristigen Trends werden im untersten Fenster angezeigt (das auf- und zugeklappt werden kann); im Beispiel der Abbildung 18.2 ist hier nur eine kurze Spitze zu sehen, da das Intervall für die gemittelten Werte 15 Minuten beträgt und das Programm erst kurz lief. Sehr hilfreich ist das Exportieren oder Drucken der Kurven; so lassen sich schnell und einfach Nachweise der Ereignisse schaffen.

476

TCP/IP Diagnose-Tools für Windows

Abb. 18.2: AnySpeed mit voller Darstellung aller drei Teilfenster

Der Autor hat erst kürzlich wieder mit AnySpeed wesentlich dazu beitragen können, Probleme auf den WAN-Leitungen eines großen Kunden zu diagnostizieren: Während nämlich die Anwender sagten: »Das Netz ist langsam« (klar!), ergab AnySpeed kurze Antwortzeiten. Es zeigte sich, dass die WAN-Leitung nicht etwa zu langsam oder verstopft war, sondern dass in den Applikationen (Windows Terminal Server/WTS/samt Clients) die TCP Data Flow Control völlig falsch lief – die langen Laufzeiten über die WAN-Leitung waren zwar ein konstituierendes Element der Verzögerungen, wären aber belanglos gewesen, wenn die TCP-Treiber korrekt gearbeitet hätten. Der einfache und schnelle Hinweis durch AnySpeed half, erst gar nicht auf eine falsche Fährte zu kommen. Es wurde in AnySpeed die IP-Adresse einer Gegenstelle in der fernen Niederlassung konfiguriert, und die entsprechende Kurve der Antworzeiten blieb stabil und zeigte einen hohen Datendurchsatz an. AnySpeed kann sofort aus dem Internet geladen und installiert werden – darum ist es ein MUSS im Doktorköfferchen eines jeden Netzwerkers.

Kapitel 18 • TCP/IP Diagnose-Tools

477

18.2.4 What’s Up Gold (Ipswitch, USA) http://www.ipswitch.com/

Die Ping-Funktion von AnySpeed hat auch What’s Up Gold (WUG) von Ipswitch, USA, und noch viel mehr Fähigkeiten, die das Programm zu einem professionellen und kommerziellen Produkt werden ließen. Automatisches Anlegen einer Netzwerkkarte (Map) WUG legt als Erstes eine Karte an, die zunächst automatisch mit Systemdaten gefüllt wird: Die in der Systemsteuerung bzw. Registry hinterlegten Router, der lokale Rechner selber sowie die WWW-Adresse von Microsoft.

Abb. 18.3: What’s Up Gold – Automatisch erzeugte Netzwerkkarte (Map)

Als Nächstes gilt es, diese Karte nach eigenen Bedürfnissen weiter zu füllen und zu formen. Das Einfachste ist, mit den eingebauten Net-Tools bzw. mit TraceRoute nach anderen Rechnern suchen zu lassen; WUG ist dann in der Lage, selber die Karte zu ergänzen. Testen eines Netzwerkrechners Inzwischen ist der Rechner www.ibm.com eingetragen worden. Mit der rechten Maustaste lässt sich ein Popup-Fenster öffnen mit der Auswahl kleiner Testprogramme, etwa Ping und TraceRoute.

478

TCP/IP Diagnose-Tools für Windows

Abb. 18.4: What’s Up Gold mit kontext-sensitivem Hilfe-Menü je Rechner

Es öffnet sich ein Fenster mit einer Auswahl von Funktionen:

Abb. 18.5: What’s Up Gold mit Testfunktionen, hier: TraceRoute

Da in der Netzwerkkarte Rechner, die nicht zuverlässig oder gar nicht mehr erreichbar sind, nicht mehr grün, sondern stattdessen gelb oder rot gefärbt werden, kann mit einem Mausklick sofort ein Test gestartet werden; die IP-Adresse bzw. der DNS-Name wird automatisch in die Tool-Maske eingesetzt.

Kapitel 18 • TCP/IP Diagnose-Tools

479

Abb. 18.6: What’s Up Gold mit Testfunktionen, hier: Ping

Abb. 18.7: What’s Up Gold mit Testfunktionen, hier: DNS Lookup

Automatische Tests Für jeden Rechner, der in der Karte erfasst ist, können eigene Regeln hinterlegt werden, wie diese Maschine zu testen ist, das heißt: welche Protokolle zu verwenden sind, in welchen Intervallen getestet werden soll, und ob im Fehlerfalle Nachrichten herausgegeben werden sollen (wie, an wen).

480

TCP/IP Diagnose-Tools für Windows

Warnung bei Fehlern Damit sich der Netzwerkverwalter auch nachts aus dem Bett klingeln lassen kann, bietet WUG die Funktion, Beeper/Pager zu benachrichtigen – wenn es denn eine einfache E-Mail nicht tut.

Abb. 18.8: What’s Up Gold – Konfiguration der Benachrichtigungen

Beispiel: Dokumentation einer Website Zurück zu der Netzwerkkarte, die noch nicht so richtig »schön« geworden ist. Es soll am Beispiel der Adresse www.bundestag.de gezeigt werden, welche Information mit WUG (oder vergleichbaren Programmen) bezogen werden können, und wie die Darstellung erfolgen kann. Mit den Net Tools wird nunmehr alles an Information über die ferne Internetdomain bzw. über einen dortigen Rechner eingeholt, die nur eben greifbar ist. Net Tools – Ping/unterstützt alle Treiber-Stapel Wichtig an der Ping-Funktion von WUG ist, dass auch Rechner, die nicht über IPICMP (Echo Request/Reply) erreichbar sind, ggf. zu einem Echo veranlasst werden können, insofern das IPX-Echo-Protokoll oder aber unter NetBEUI eine entsprechende LLC-Protokoll-Funktion verwendet wird.

Kapitel 18 • TCP/IP Diagnose-Tools

481

Abb. 18.9: What’s Up Gold – Net Tools – Ping

Dies bedeutet mit anderen Worten, dass alle drei Protokollstapel von Windows beim Echotest unterstützt werden: •

NetBEUI (LLC)

•

NWLink (IPX)

•

NetBT (TCP/IP)

Einfache Ping-Programme bieten diesen Service nicht. Net Tools – TraceRoute/baut automatisch die Karte auf Der TraceRoute-Mechanismus wurde bereits im Abschnitt 18.1.9 beschrieben. Hier nun in WUG erfolgt die Ermittlung aller Router, ihrer IP-Adresse und DNSNamen; es erfolgt aber auch das automatische Eintragen der Router und Gegenstellen in die Netzwerkkarte (siehe das Kreuzchen bei »Map«). Die Karte sieht dann etwa so aus wie Abbildung 18.11 (nachdem die Symbole für die Router etwas sortiert wurden). Hier wurde außer dem WWW-Server des Deutschen Bundestages auch die Stadt Trier besucht, weil es dort einige interessante SNMP-Informationen zu holen gibt, so z.B., dass der dortige Webserver eine Linux-Maschine ist. Das soll jetzt aber mal außer Betracht bleiben.

482

TCP/IP Diagnose-Tools für Windows

Abb. 18.10: What’s Up Gold – Net Tools – Traceroute

Abb. 18.11: What’s Up Gold – Net Tools – mittels TraceRoute aufgebaute RoutingKarte des WWW

Kapitel 18 • TCP/IP Diagnose-Tools

483

Net Tools – DNS LoopUp/Provider-Infos und mehr Als Nächstes wird mit DNS-LookUps nicht nur der WWW-Name in die IPAdresse aufgelöst; das ist bei Ping und TraceRoute ja schon längst geschehen. Nein, das Interessante an den DNS-Abfragen sind die Hinweise auf Provider, Mail-Systeme und dergleichen mehr.

Abb. 18.12: What’s Up Gold – Net Tools – DNS LookUp (1)

Es wird Folgendes ersichtlich: •

Die DNS-Server sind dns.bull.de, koeln.nic.xlink.net und xlink1.xlink.net.

•

Der Deutsche Bundestag lässt seinen Webserver offenkundig über den Dienstleister Bull betreuen.

•

Den Internetzugang erledigt einer der größten Internetprovider Europas, nämlich Xlink.

•

Das Ganze dürfte schon eingerichtet worden sein, als die Regierung noch in Bonn war, da sonst nicht unbedingt ein DNS-Server in Köln eingetragen wäre.

Die weiteren Details der DNS-Anfragen offenbaren am Ende viele Rechner des Providers; es ist nicht schwer, die Präsenz eines Providers in den verschiedenen Regionen zu ermessen.

484

TCP/IP Diagnose-Tools für Windows

Abb. 18.13: What’s Up Gold – Net Tools – DNS LookUp (2)

Net Tools – Port Scan/welche Dienste auf welchem Rechner Das gezielte »Anklopfen« bei fremden Rechnern unter den verschiedenen Dienstekennungen (UDP/TCP Ports) gehört zu den Standardtests, um die Fähigkeiten anderer Rechner zu erfahren. Hacker benutzen das Port Scanning gerne. Im Falle des Deutschen Bundestages wird die IP Address Range (der Adressraum) etwas ausgeweitet: Statt nur die IP-Adresse 194.120.12.110 abzufragen, werden alle Rechner im Bereich der Endnummern 100-120 abgefragt. Es zeigt sich, dass der vermutete Dienstleister Bull die Nachbaradressen belegt hat; weiter zeigt sich, dass der Deutsche Bundestag (mindestens) noch einen zweiten Webserver am Netz hat (www2.bundestag.de). Der Hinweis auf die unterstützten Protokolle kann für weitere Unternehmungen genutzt werden – das aber überschreitet dann die »Netiquette« und gleitet in die rechtliche Grauzone ab, in der schon vielleicht der Staatsanwalt wartet. Wie so ein Angriff aussehen könnte, ist im Abschnitt 18.3 dargestellt. Net Tools – Antwortzeiten und Durchsatz/ist das Netz verstopft? Nun wollen wir ja nichts Böses – wir wollten nur einmal bei unseren Volksvertretern vorbeisehen (wenngleich auch durch die Hintertür, gewissermaßen).

Kapitel 18 • TCP/IP Diagnose-Tools

485

Abb. 18.14: What’s Up Gold – Net Tools – Port Scan

In Abschnitt 18.2.3 wurde AnySpeed vorgestellt, das mit dem Mittel von Ping die Verfügbarkeit des Netzes mit Blick auf die Antwortzeit und auf den daraus abgeleiteten (hochgerechneten) Datendurchsatz prüft. Die Funktion ist bei WUG nicht grafisch unterstützt; aber auch die Tabellenform reicht aus. Sie ist sogar geeignet wesentlich mehr Details zu liefern. Eine wesentlich ausführlichere Anzeige ist in Abbildung 18.17 zu sehen. Differenzen in der Durchsatzanzeige Der Algorithmus, mit dem aus Ping-Antwortzeiten auf den vermutlich erreichbaren Datendurchsatz geschlossen wird, ist ein Geheimnis bzw. ein Kunststück für sich. Es muss erkannt werden, dass What’s Up Gold und AnySpeed bei denselben Verbindungen andere absolute Werte für den Throughput anzeigen. Das ist aber nicht so entscheidend. Wichtig ist, dass beide Programme in jedem Falle denselben Kurvenverlauf zeigen. Sie stimmen also nicht absolut, aber doch relativ überein. Da der Betrachter, in aller Regel schließlich ein Netzwerk-Administrator, im Laufe der Zeit die Tageskurve kennt sowie die üblichen Schwankungen, kann ein »Ausreißer« sofort erkannt werden – in beiden Programmen.

486

TCP/IP Diagnose-Tools für Windows

Abb. 18.15: What’s Up Gold – Net Tools – Datendurchsatz

Mini-Status Es wurde bereits beim Port Scan nach den unterstützten Ports eines fernen Rechners gefahndet.

Abb. 18.16: What’s Up Gold mit Anzeige der verfügbaren Dienste

Kapitel 18 • TCP/IP Diagnose-Tools

487

Es lassen sich in WUG für jeden überwachten Rechner die Dienste bzw. UDP/ TCP-Ports genau bestimmen, die überwacht werden sollen. Sodann führt WUG in regelmäßigen Abständen (die ebenfalls frei festgelegt werden können) eigenständig einen Port Scan durch; im Ergebnis erzeugt das Programm eine übersichtliche Tabelle über die erreichbaren Dienste bzw. Ports. Im Beispiel der Abbildung 18.16 sind die nicht verfügbaren Ports dunkel gefärbt, die erreichbaren hell (real natürlich in Farbe). Verbindungsstatus/Antwortzeiten

Abb. 18.17: What’s Up Gold – Tabelle der Antwortzeiten und Ausfälle

Die wirklich wichtigen Angaben zur Erreichbarkeit und Verfügbarkeit von Rechner sind in einer einzigen Tabelle zusammengefasst (siehe Abbildung 18.17), so etwa das Protokoll, die Beobachtungszeit, die Zahl der Testzyklen (Pollings), die Antworten auf Anrufe in Prozent, Antwortzeiten, Ausfallzeiten und weiteres mehr. Erkennung lokaler Resourcen auf dem Campus (LAN) Neben der Internetfähigkeit beitet WUG zuletzt noch die automatische Erkennung aller LAN-Ressourcen. Die in Abbildung 18.18 ersichtliche Bezeichnung dieser Funktion als »WinNet« führt in die Irre, da z.B. auch NetWare-Server erkannt und angezeigt werden. Die Ergebnisausgabe dieser Funktion entspricht etwa der Ansicht im WindowsExplorer bzw. in der sog. Netzwerkumgebung.

488

TCP/IP Diagnose-Tools für Windows

Abb. 18.18: What’s Up Gold – Auskunft über alle LAN-Ressourcen

Alle Resourcen auf einen Blick (LAN/WAN) Die sowohl aus LAN wie aus WAN bekannt gewordenen Ressourcen sind am Ende in einer gemeinsamen Ressourcenliste abgelegt. Diese Anzeige bzw. Liste umfasst wirklich alle Ressourcen, auch solche, die nicht in der Netzwerkkarte (Map) aufgeführt sind. Der krönende Abschluss: Eine schöne Karte Die bereits in Abbildung 18.11 gezeigte Routing-Karte wird noch hier und da durch Zurechtrücken der Symbole verbessert, und zum Schluss wird eine echte Landkarte hinterlegt, sei das nun ein Campusplan, ein Gebäudeplan oder ein Organigramm. Das Beispiel aus Abbildung 18.20 zeigt nur die mitglieferte Weltkarte; dies entspricht natürlich nicht der tatsächlichen geografischen Verteilung, wie sie bei unserem Streifzug sichtbar wurde (Berlin, Köln, Karlsruhe).

Kapitel 18 • TCP/IP Diagnose-Tools

Abb. 18.19: What’s Up Gold – Liste aller gefundenen Ressourcen

Abb. 18.20: What’s Up Gold mit fertiger Netzwerkkarte

489

490

18.3

(Freundlicher) Angriff auf eine Website

(Freundlicher) Angriff auf eine Website Die Beispiele aus Abschitt 18.2 waren im Ganzen recht harmlos und dienten eher der Vorstellung der beiden Software-Tools.

18.3.1 Einleitung: Nachahmung wird nicht empfohlen! Das nachfolgende Beispiel ist durchaus nicht mehr so harmlos – es geht an die Grenze dessen, was rechtlich eben noch machbar ist. Wer immer diesen Abschnitt liest, möge seine eigenen Schlüsse daraus ziehen. Sicher ist, dass nichts sicher ist, wenn man sich im Internet offenbart. Wer ein ganzes Campusnetz dem Internet gegenüber öffnet, ohne via Firewall die nötigen Vorkehrungen zu treffen, um Eindringlinge »draußen« zu halten, darf sich nicht wundern, wenn sich am Ende ein Einbrecher auf einmal - virtuell - im Rechenzentrum befindet. Das folgende Beispiel wurde im Dezember 1999 dokumentiert. Die vollständige Gruppe der RZ-Verantwortlichen des betroffenen Netzwerkes wurden vom Autor ausführlich informiert, damit sie noch vor Erscheinen des Buches Gelegenheit haben würden, ihr Netz »dicht« zu machen.

18.3.2 Besuch bei der Fachhochschule Emden Mit dem Programm »What’s Up Gold« werden ein paar einfache Abfragen auf einen nicht ganz beliebigen Rechner im Internet durchgeführt. In diesem Beispiel ist es ein Server der Fachhochschule Emden: server.et-inf.fho-emden.de

18.3.3 Schritt A: TraceRoute Es wird ein TraceRoute durchgeführt. Hierbei wird der Weg durchs Internet bis zur Zieladresse erforscht. Es wird erkannt, dass die Fachhochschule Emden ans »Deutsche Forschungsnetz« (DFN) angeschlossen ist. Diese Auskunft gehört zur Offenheit des Internets und ist ganz normal. Sie offenbart zunächst einmal einen Teil der Netzstruktur (DNF) sowie die IP-Adressen der Router sowie des Webservers 192.129.16.1 (die DNS-Abfrage lief im Hintergrund). Es lohnt sich, TraceRoute an verschiedenen Tagen durchzuführen, da im Laufe der Zeit verschiedene Routen auftreten werden.

Kapitel 18 • TCP/IP Diagnose-Tools

491

Abb. 18.21: What’s Up Gold – TraceRoute nach Emden

18.3.4 Schritt B: Finger Nun wird versucht, die Namen der dort am Rechner eingeloggten Benutzer abzufragen. Das hierzu gebräuchliche Programm Finger ist besonders auf vielen UnixMaschinen zu finden. Der Versuch hat Erfolg – es sind einige Benutzer zu erkennen. Möglicherweise ist den dort arbeitenden Benutzern gar nicht bewusst, dass der Rechner, auf dem sie arbeiten, ihre Anwesenheit im Internet publiziert. Im schlechtesten Falle werden jetzt schon Vorschriften des Datenschutzes verletzt – nicht vom Abfragenden, sondern seitens des dortigen Systemadministrators. Es sind erste Aufschlüsse zu gewinnen: A. Root User/Admin Ingo Herz dürfte selber Admin sein, da er unmittelbar an der Unix-Konsole arbeitet. Dies erschließt sich aus der Angabe TTY=02 (s.u.). B. Normale Anwender/Netzwerk-Terminals Die anderen dürften »normale« Benutzer sein, da sie über Netzwerk-PCs arbeiten bzw. über Terminal-Emulation (Software).

492

(Freundlicher) Angriff auf eine Website

Abb. 18.22: What’s Up Gold – Finger (wer ist eingeloggt?)

Dieses ist ersichtlich aus der Bezeichnung TTY=p1 etc., wobei die Bedeutungen wie folgt sind: •

TTY=TeleType

•

TTY p0 = Pseudo-Terminal 0/der erste LAN-PC, der sich angemeldet hat

•

TTY 02 = echtes, serielles Terminal bzw. die Rechnerkonsole (Admin)

C. Uhrzeiten (Arbeitszeiten) Wir erfahren, um welche Uhrzeit sich die Anwender eingeloggt haben. D. Persönliche Angaben Wir erfahren sogar eine Telefonnummer, die in den Stammdaten des betroffenen Benutzers hinterlegt sind. E. Terminal-Finger Ein »echter« Finger-Befehl an einem ASCII-Terminal hätte die Ausgabe in tabellarischen Spalten wie folgt formatiert: Login herz stegoh mike96 ericb

Name TTY Idle When Office Ingo Herz 02 15 Wed 07:46 T208 324 Stefan Gohmann *p0 15 Thu 08:37 Michael Lang p1 5 Thu 12:54 0441/507700 Eric Bartels p2 30 Thu 13:49

Kapitel 18 • TCP/IP Diagnose-Tools

493

F. Ansatz für Hacker oder Einbrecher Ein böswilliger Hacker hätte jetzt schon Anhaltspunkte für ein mögliches Vorgehen. Andererseits sind dies noch Angaben, die ggf. auch noch über Telefonauskunft oder die Homepage der Fachhochschule erhältlich gewesen wären (das ist teilweise so). Die Nicht-Abschottung gegenüber Finger-Abfragen ist jedenfalls extrem gefährlich, weil ein böswilliger Hacker als Nächstes versuchen könnte, zu den bekannten Benutzernamen die Passworte zu knacken – denn mit dem Wissen um die Benutzernamen sind 50% der Zugangsschwelle bereits erklommen.

18.3.5 Schritt C: Port Scan Als Nächstes wird versucht herauszufinden, welche Prozesse bzw. Services auf dem Server (besser: auf allen Rechnern der Domain) in der Fachhochschule Emden geladen und via Internet ansprechbar sind. Die Port-Scan-Funktion von What’s Up Gold bekommt hierzu zwei IP-Adressen genannt, die den IP-Adressraum kennzeichnen, der abgesucht werden soll. In diesem Beispiel sollen alle Rechner mit den IP-End-Ziffern .1 bis .255 abgesucht werden – was allen Rechnern des Class-C-Netzes 192.129.16.x entspricht. In der Tat antworten ziemlich viele Rechner – die Abfrage war ein voller Erfolg.

Abb. 18.23: What’s Up Gold – Port Scan – erkannte Dienste (1)

494

(Freundlicher) Angriff auf eine Website

Abb. 18.24: What’s Up Gold – Port Scan – erkannte Dienste (2)

Abb. 18.25: What’s Up Gold – Port Scan – erkannte Dienste (3)

Kapitel 18 • TCP/IP Diagnose-Tools

495

Wie aus Abbildung 18.23 ff. klar ersichtlich, haben viele Rechner in der FHO Emden eine Menge Dienste geladen – kommt daher das Wort Einladung? Die gefährlichsten Dienste bzw. Ports Einige Dienste laden zum Hackereinbruch geradzu ein – eine gefährliche Situation. Hierzu gehören vor allem Rechner mit folgenden Diensten: •

SNMP – Netzwerk-Management

•

SMTP, POP3 – E-Mail

•

FTP – File Transfer Protocol

•

NFS – Network File System

Alle Rechner, die per Port Scan als Anbieter der genannten Dienste erkannt wurden, dürften damit die ersten Ziele von Angriffen sein. Protokollanalyse Hier wird interessant, was sich auf Protokollebene abspielt. Dies macht der Protokollanalysator deutlich (Abbildung 18.26, Abbildung 18.27).

Abb. 18.26: LANdecoder32: Der Port Scan mit POP-3 Abfrage (1)

•

Mit Paket 423 ruft der auswärtige Rechner (der Eindringling) mit IP=195.14.251.87 auf dem Zielrechner mit IP=192.129.16.5 den TCP-Port 110 (POP3) mit TCP-SYN an; der Source-Port ist 2501.

•

In Paket 425 kommt schon die Bestätigung mit TCP-SYN/ACK.

496

(Freundlicher) Angriff auf eine Website

•

Da dies als Nachweis des POP3-Dienstes (Daemons) auf dem Zielrechner schon ausreicht, sendet der Eindringling dann schon TCP-FIN in Paket 427.

•

Dies aber hält den POP3-Rechner nicht davon ab (stolz, wie er ist), mit Paket 434 eine POP3-Nachricht zu schicken, um sich zu identifizieren: »watt.etinf.fho-emden.de«.

Dass es sich bei der Antwort des POP3-Rechners tatsächlich um eine Reaktion auf den Ruf in Paket 423 handelt, zeigt die Abbildung 18.27:

Abb. 18.27: LANdecoder32: Der Port Scan mit POP-3 Abfrage (2)

Neben den IP-Adressen sind jetzt in Paket 434 auch die TCP-Ports erkennbar, und dies sind dieselben Ports wie im TCP-SYN-Ruf in Paket 423. Weiter unten wird auf die besondere Bedeutung von Mail-Zugängen hingewiesen.

18.3.6 Schritt D: SNMP Get sysInfo/sysDescr Es wird nunmehr versucht, auf einem der erkannten IP-Rechner den via Port Scan entdeckten SNMP-Agenten abzufragen. Und: voller Erfolg! Community String »public« Die Admins der FHO-Emden hatten es versäumt, das Passwort (Community String) vom »factory default« (von der vorgegebenen Einstellung also) in ein anderes abzuändern. Viele, wenn nicht gar die meisten SNMP-Produkte werden mit dem Standardeinstellung des Community Strings auf »public« ausgeliefert – so auch hier.

Kapitel 18 • TCP/IP Diagnose-Tools

497

Nun ist »public« nur das Passwort für die Lesezugriffe; aber es gibt schließlich auch einen Standard für die Lesezugriffe. Nun wäre es ggf. möglich, mit einer SNMP-Console restlos alle Operationen auszuführen, die der ferne SNMP-Agent bietet – einschließlich von Cold Boot oder Packet Capture via RMON (sofern vorhanden und geladen). Spätestens dann wäre das angegriffene Netz nicht nur in Gefahr, sondern ggf. auch funktionsunfähig. Auskunft über verschiedene Rechner Zwei Rechner seien hier als Beispiel aufgeführt: Watt und Tony.

Abb. 18.28: What’s Up Gold – SNMP GetSysInfo – Rechner »Watt«

Die Angaben aus Abbildung 18.28 lesen sich wie folgt: SysName: watt IBM PowerPC CHRP Computer Machine Type: 0x0800004c Processor id: 004228064C00 Base Operating System Runtime AIX version: 04.02.0001.0000 TCP/IP Client Support version: 04.02.0001.0000 Listing 18.1: Die Systemangaben des Rechners »Watt«

498

(Freundlicher) Angriff auf eine Website

Abb. 18.29: What’s Up Gold – SNMP GetSysInfo – Rechner »Tony« SysName: tony IBM RISC System/6000 Machine Type: 0x0801 Processor id: 000036334600 The Base Operating System AIX version: 03.02.0000.0000 TCPIP Applications version: 03.02.0000.0000 Admin: Frank Kalms, Tel.: 203, Raum V109 Standort: FHO, FB E+I, V210 Listing 18.2: Die Systemangaben des Rechners »Tony«

Angaben zum Betriebssystem Mit diesen Angaben könnte sich ein Angreifer etwaige bekannte Schwächen des via SNMP erkannten Betriebssystems zunutze machen. Im vorliegenden Beispiel würde das bedeuten: Gäbe es bekannte Schwachstellen bei AIX (IBM Unix), so könnten sie jetzt ggf. genutzt werden. Und wenn dann noch, wie im gegebenen Beispiel, der Admin mit Name und Telefonnummer genannt wird sowie die Raumnummer, so ergeben sich daraus ggf. Hinweise, wo etwas zu holen ist.

Kapitel 18 • TCP/IP Diagnose-Tools

499

Hier wird ein Zielkonflikt deutlich sichtbar: Solche Angaben haben (hatten) eigentlich den Zweck, die Verwaltung des Netzwerkes und seiner Geräte zu erleichtern. Heute aber kann diese Offenheit in Verwundbarkeit umschlagen.

18.3.7 Schritt E: SNMP Get ifPhysAddress Nun geht es tiefer in die Hardware hinein.

Abb. 18.30: What’s Up Gold – Auswahl des SNMP-Parameters MIB-Baum

Zunächst wird der Parameter gesucht, der abgefragt werden soll. Bei den vorherigen Abfragen war die Systembeschreibung abgefragt worden – in der Sprache von SNMP sysDescr genannt: System Description. Jetzt wird unter dem Punkt interfaces die MAC-Adresse des beobachteten Rechners ausgelesen. Wie in Abbildung 18.32 zu sehen ist, gibt der ferne Rechner tatsächlich die Adresse seines LAN-Adapters bekannt: MAC=08005AC76E30

Für einen späteren Einbruch ins Netz kann das durchaus hilfreich sein – beispielsweise dann, wenn der Einbrecher sich Zutritt zum Campus verschaffen kann und dann seine »Netzwerkumgebung« bereits kennt.

500

(Freundlicher) Angriff auf eine Website

Abb. 18.31: What’s Up Gold – SNMP-Parameter »ifPhysAddress«

Abb. 18.32: What’s Up Gold – Die MAC-Adresse des fernen Rechners

Kapitel 18 • TCP/IP Diagnose-Tools

501

18.3.8 Schritt F: SNMP Get ifInOctets Es lassen sich weiterhin die Maschinenstatistiken ganz simpel auslesen. Die folgenden Bilder zeigen das (Abbildung 18.33 und Abbildung 18.34).

Abb. 18.33: What’s Up Gold – SNMP-Parameter »ifInOctets«

Abb. 18.34: What’s Up Gold – laufende Statistik des Paketdurchsatzes

502

(Freundlicher) Angriff auf eine Website

Nunmehr wird in festen Intervallen der Paketdurchsatz ausgelesen und angezeigt. Womöglich hat der ferne Lauscher nun besseres Netzwerk-Management als der Verwalter des Maschine selber – in jedem Falle aber hat der Fremdling schon viel zu viel abfragen können.

18.3.9 Schritt G: DNS LookUp/weitere Betreiber des RZ Als Nächstes wird ein weiterer Beteiligter ausfindig gemacht, der vermutlich am Rechenzentrum (RZ) beteiligt ist:

Abb. 18.35: What’s Up Gold – DNS-Abfrage der Authority-Daten

Wie Abbildung 18.35 zeigt, sind nicht nur Rechner der FHO-Emden beteiligt, sondern auch eine Maschine namens niesel.dkrz.de (Name Server) – die Maschine dürfte für die Berechnung von »Nieselregen« zuständig sein, da »dkrz« für das »Deutsche Klimarechenzentrum« steht.

18.3.10 Schritt H: DNS LookUp/Mail System Ein wirklich böswilliger Hacker würde jetzt noch den vorletzten Schritt gehen und sich so noch Daten zum Mail-System einholen.

Kapitel 18 • TCP/IP Diagnose-Tools

503

Abb. 18.36: What’s Up Gold – DNS-Abfrage zum Mail Exchange (MX)

Das Ergebnis der DNS-MX-Abfrage (Abbildung 18.36) weist aus: postmaster.watt.et-inf.fho-emden.de

Damit ist ein erster Ansatzpunkt für den gefährlichen Angriff auf das Mail-System gegeben.

18.3.11 Schritt I: Der Angriff auf das Mail-System Der letzte Schritt eines böswilligen Angreifers könnte sein, Mails an die erkannten Mail-Server zu senden, um sie zu Rückantworten (»Benutzer unbekannt« etc.) zu animieren; diese Fehlermeldungen enthalten sehr oft ihrerseits Angaben, die sich der Hacker später zunutze machen kann. Header und Trailer (Kopfteil, Fußteil) von E-Mails enthalten sehr detaillierte Angaben über die verschiedenen Mail-Server einer Domain; bei jeder InternetE-Mail lässt sich das nachvollziehen. So stehen teilweise bis heute in Mails von T-Online-Kunden nicht nur die AliasNamen, etwa [email protected], sondern auch die Telefonnummern – sofern man nur eben den Header lesbar macht.

504

Hacker-Tools

Ansonsten sind E-Mails beliebt, weil sie sich traditionell in Attachments, also anhängenden Dateien, Programm-Viren verbreiten lassen. Ende 1999 wurde erstmals ein neuartiger Virus-Typ bekannt, der sich sogar im normalen Text der E-Mail befindet. Somit sind Angriffe über das Mail-System für den Hacker besonders »lohnend«. Dies hat außerdem damit zu tun, dass Mails von FirewallSystemen kaum behindert werden. Wer immer eine Firewall überwinden will, tut dies mit E-Mails. Dann aber droht schon Besuch vom Staatsanwalt, und deshalb hören unsere Versuche an dieser Stelle auf.

18.3.12 Fazit Wir haben mit unserem kleinen Versuch sehr viel über ein fremdes Netz in Erfahrung bringen können. Zu viel – denn die Sicherheit des besuchten Netzes ist nunmehr in einiger Gefahr. Wer immer unter den Lesern Verantwortung für Rechenzentren und lokale Netze zu tragen hat, möge seine Schlüsse daraus ziehen, was er noch für die Sicherheit der ihm anvertrauten Technik und Daten zu tun hat.

18.4

Hacker-Tools Wer glaubt, dass das Beispiel aus Absatz 18.3 einigermaßen beunruhigend wäre, hat noch keine »professionellen« Hacker-Tools gesehen. Die wirklich »guten« Programme machen alles das, was hier umständlich Schrittfür-Schritt erledigt wurde, im Handumdrehen. Auch das Herausfinden von Schwachstellen im Mail-System ist durchaus effizienter zu gestalten, als es hier angedeutet wurde. Der Autor nimmt davon Abstand, hier auf Software hinzuweisen, die ein fremdes System wie ein Dosenöffner knackt – jeder Leser kann das für sich tun. Es sollte Folgendes gezeigt werden: Kein Netzwerker, der einigermaßen gut ausgestattet ist, muss sich umgekehrt erst noch ein echtes Hacker-Tool besorgen, um tief in fremde Systeme einsteigen zu können. Selbst die recht einfachen Tools können das schon tun. Es wird darum dringend empfohlen, sich mit den gängigen Sicherheitstechniken auseinander zu setzen. Es wird zu diesem Zwecke verwiesen auf einen Bestseller des Verlages:

Hinweis Hacker's Guide – Sicherheit im Internet und im lokalen Netz.

Autor: anonym München (Markt & Technik Verlag) 1999, ISBN 3-8272-5460-4, 832 Seiten, mit CD-ROM, DM 89.95

Kapitel 19 Troubleshooting mit TCP/IP 19.1 19.2 19.3 19.4 19.5 19.6

IP-Host antwortet nicht: Ping IP TTL (Time To Live): TraceRoute Routing-Fehler: ICMP & Expertendiagnose Netzwerk langsam: Durchsatzmessung IP-Pakete gehen verloren: Paketanalyse Filter setzen auf IP und ARP

506 508 514 518 519 520

506

IP-Host antwortet nicht: Ping

Die folgenden Abschnitte beschreiben Vorgehensweisen bei Fehlersuche in IPNetzen. Es können und sollen hier nicht alle Szenarien für TCP/IP-Fehler aufgezeigt werden. Und doch sind die überwiegenden Standardfehler hier erfasst. Dieses kleine Kapitel ist gedacht für den Fall, dass •

Sie entweder das Buch nicht mehr gut in Erinnerung haben, oder

•

Sie es überhaupt noch nicht haben lesen können,

•

Sie aber schnell handeln müssen, ohne lange zu lesen.

Voraussetzung ist natürlich, dass Sie über vergleichbare Messmittel verfügen wie die hier dargestellten. Es müssen nicht dieselben sein – es reicht, wenn Sie vergleichbare Produkte einsetzen. Dieses kleine Kapitel soll Ihnen einen kurzen, schnellen »roten Faden« liefern. Die Stichworte sind:

19.1

•

IP-Host antwortet nicht: Ping

•

IP TTL low (Time To Live): TraceRoute

•

Routing-Fehler: ICMP & Expertendiagnose

•

Netzwerk ist langsam: Durchsatzmessung

•

IP-Pakete gehen verloren: Paket-Analyse

•

Filter setzen auf IP und ARP

IP-Host antwortet nicht: Ping Problem: Ein angerufener IP-Host antwortet nicht. Diagnose: Mit Ping = »ICMP: Echo Request/Reply« wird festgestellt, ob der IP-Teilnehmer erreichbar ist. Beispiele: WSPing32 (Ipswitch, USA), What’s Up Gold (Ipswitch, USA). Das in Abbildung 19.1 gezeigte Programm WS_Ping erfreut sich zwar allgemeiner Beliebtheit, hat aber nicht genügend Möglichkeiten zur Anpassung der nötigen Parameter.

Kapitel 19 • Troubleshooting mit TCP/IP

507

Abb. 19.1: WS_Ping – ohne Anpassung der Paketgröße

Insbesondere ist es notwendig, mit verschiedenen Paketgrößen senden zu können, um mögliche Probleme beim IP Fragmenting seitens der Router sichtbar machen zu können.

Abb. 19.2: What’Up Gold – mit allen Möglichkeiten für ein gutes Ping

508

IP TTL (Time To Live): TraceRoute

Das bereits im Kapitel 18 »TCP/IP Diagnose-Tools« ausführlich beschriebene Programm What’s Up Gold bietet die nötigen Möglichkeiten, durch Veränderung der Paketgröße auch Fragmentierungsfehlern auf die Schliche zu kommen.

19.2

IP TTL (Time To Live): TraceRoute Problem: IP-Pakete erreichen den Empfänger nicht, weil die Zahl der zu überquerenden Router zu groß und der Hop Credit der IP-Pakete zu klein ist, heißt: weil der TTLWert bei Senden der IP-Pakete zu gering ist.

Abb. 19.3: What’s Up Gold – TraceRoute – Timeout/keine Antwort

Kapitel 19 • Troubleshooting mit TCP/IP

509

Diagnose: 1. TraceRoute mit ansteigenden TTL-Werten, beginnend bei 1, endend bei dem als ausreichend festgestellten TTL-Wert. 2. Mitlesen aller ICMP-Meldungen mit einem Protokoll-Analysator. Ein Router, bei dem der TTL-Wert eines IP-Paketes auf Null fällt, muss (...sollte...) dies mit »ICMP: Time Exceeded« melden. Beispiele: What’s Up Gold (Ipswitch, USA), LANdecoder32 (Triticom, USA). Der TraceRoute-Test liefert im Erfolgsfall die eindeutige Meldung, dass der gesuchte IP-Host erreicht wurde: »host reached« (oder ähnlich). Warnung Falle! Der Umstand, dass keine Antwort kommt, ist nicht notwendig ein Beweis für einen Fehler. Ein bekanntes Beispiel ist seit zwei Jahren die Website von Microsoft. Wie Abbildung 19.3 zeigt, ist beim Ruf nach www.microsoft.com keine Antwort vom entsprechenden Webserver gekommen. Dies könnte den Verdacht begründen, dass Pakete im Netzwerk (hier: im Internet) hängen bleiben, weil sie zu groß sind und ggf. die Fragmentierung nicht sauber läuft. Also wird mit Ping mal mit 1.500 Bytes, mal mit 64 Bytes gesendet. Das Textfeld der Ping-Funktion (Abbildung 19.4) zeigt jeweils zu Beginn des Tests eine Statuszeile: •

Ping www.microsoft.com 5/5000/1500/1 (Pakete mit 1.500 Bytes)

•

Ping www.microsoft.com 5/5000/64/1 (Pakete mit 64 Bytes)

Der sofort hinterher vollzogene Gegentest auf die Adresse www.bundestag.de beweist, dass es keine allgemeine Netzwerkstörung ist – der Webserver des Deutschen Bundestages wird einwandfrei erreicht. Aber – gleichzeitig lässt sich im Webbrowser sehr wohl die Webpage von www.microsoft.com aufrufen.

510

IP TTL (Time To Live): TraceRoute

Abb. 19.4: What’s Up Gold – Ping mit 1.500 Bytes und 64 Bytes

Abb. 19.5: Netscape: Die Homepage von Microsoft wird erreicht.

Kapitel 19 • Troubleshooting mit TCP/IP

511

Was also ist passiert? Ein einfaches DNS-Lookup zeigt (Abbildung 19.6):

Abb. 19.6: What’s Up Gold: Die IP-Adresse der Microsoft-Domain

Man sehe sich noch einmal die letzte IP-Adresse im Internetweg von TraceRoute an – das war ... 207.46.129.132 = icmpscomc7502-a1-00-1.cp.msft.net

... während die Domain-Adresse 207.46.131.28 etc. lautet. Dies führt zu den Annahmen, •

dass das Microsoft-Netzwerk zwar mit dem Router 207.46.129.132 (...msft.net) erreicht wurde,

•

dass aber entweder diese Maschine zugleich eine Firewall ist, die den PingVersuch abwehrt,

•

oder dass spätestens der nächste Router nach 207.46.129.132 die Firewall ist.

Nachdem noch im Jahre 1997 die Microsoft-Domain unter Hackerangriffen aus dem Internet arg zu leiden hatte, machte Microsoft danach »zu« wie kaum ein anderer Internetteilnehmer.

512

IP TTL (Time To Live): TraceRoute

Ergebnis: Aus der fehlenden Antwort durften keine falschen Schlüsse gezogen werden! Analyse: Derselbe Vorgang sieht im Protokoll-Analysator so aus:

Abb. 19.7: LANdecoder liest am PPP-Adapter TraceRoute und Ping mit

Abb. 19.8: Der letzte, beantwortete TraceRoute-Ping – danach: Leerlauf

Kapitel 19 • Troubleshooting mit TCP/IP

513

In Abbildung 19.8 ist der mit What’s Up Gold durchgeführte TraceRoute-Test zu sehen •

In Paket 92 kommt die letzte Router-Meldung »ICMP: Time Exceeded«.

•

In Paket 93 ist die ebenfalls letzte DNS-Abfrage nach der IP-Adresse dieses letzten Routers (IP=207.46.129.132, bei DNS umgekehrt dargestellt als 132.129.46.207).

•

In Paket 94 kommt die Antwort, im kleinen Fenster unten links dargestellt.

•

In Paket 95 und 96 wird der Ping mit demselben TTL-Wert wiederholt, da das TraceRoute-Programm in What’s Up Gold Pings mit einem jeweils erreichten TTL-Wert jeweils doppelt durchführt. Daher antwortet derselbe Router erneut – dabei fällt TTL auf Null.

•

Ab Paket 97 laufen die Pings ins Leere – es gibt keine Antwort mehr.

Dieser Zustand, dass jede Rückantwort fehlt, ist typisch für ganz besonders schweigsame Firewall-Systeme, die darum auch gerne Black Holes (Schwarze Löcher) genannt werden: Was kommt, wird verschluckt, abgegeben wird nichts. Die letzte ICMP-Rückmeldung aus Paket 96 soll noch genau betrachtet werden (Abbildung 19.9).

Abb. 19.9: Die letzte ICMP-Meldung vor dem »Schwarzen Loch«

514

Routing-Fehler: ICMP & Expertendiagnose

Im Fenster links ist oben die Absender-IP-Adresse zu sehen: 207.46.129.132 – dies ist der Microsoft-Router icmpscomc7502-a1-00-1.cp.msft.net. Als Empfänger ist die lokale Ping-Station adressiert: 194.8.205.78. Darunter (immer noch links) ist der ICMP-Header zu sehen mit der Meldung »ICMP: Time Exceeded«. Der Decoder zeigt dann zudem an, dass hinter ICMP noch der IP-Header des vom Router verworfenen IP-Pakets folgt: »Internet header of originating message follows.« Die ersten Auflösungen dieses IP-Headers sind links noch zu sehen. Im Fenster rechts ist dann die vollständige Kopie des verworfenen IP-Headers zu sehen; an den IP-Adressen, die unten rechts zu sehen sind, ist das schließlich erkennbar: Absender ist die lokale Ping-Station 194.8.205.78, Empfänger ist die IP-Adresse der Microsoft-Domain www.microsoft.com.

19.3

Routing-Fehler: ICMP & Expertendiagnose Problem: Der angerufene Host in online, er antwortet auch sporadisch auf Ping-Rufe. Warum dann aber bricht zwischendurch die Kommunikation zusammen? Diagnose: Ein Protokoll-Analysator liest den Datenverkehr mit, vorrangig die ICMP-Meldungen. Sofern Router an dem Fehler beteiligt sind, ist die Wahrscheinlichkeit von ICMP-Rückmeldungen seitens der Router sehr groß. Beispiel: LANdecoder32 (Triticom, USA). Das gegebene Beispiel zeigt einen seltenen Doppelfehler: Zwei Fehler tauchen gleichzeitig auf. Oder, anders gesagt: Ein WinNT-Server und zwei Router bilden ein unglückliches Dreiecksverhältnis (so etwas soll ja selten gutgehen...). Der Router mit IP=194.233.0.2 sendet »ICMP: Source Quench« an den Host mit IP=194.233.0.86. Die ICMP-Meldung offenbart, dass ein Paket von IP=194.233.0.86 verworfen werden musste, weil der Router überlastet war. Abbildung 19.11 zeigt die vollständige ICMP-Meldung; der Router sendet eine Kopie des IP-Headers aus dem von ihm verworfenen IP-Paket zurück. Nach der ICMP-Meldung des Routers 194.233.0.2 schickt der Host 194.233.0.86 die Daten eben an den Router 194.233.0.1; dieser erkennt jedoch, dass er nicht die richtige Adresse ist für das Weiterreichen bestimmter IP-Pakete, und meldet dies über »ICMP: Redirect« zurück an 194.233.0.86: Der Absender möge sich doch bitte!- wieder an 194.233.0.2 wenden!

Kapitel 19 • Troubleshooting mit TCP/IP

Abb. 19.10: LANdecoder32: Router meldet »ICMP: Source Quench«

Abb. 19.11: LANdecoder32: Die ICMP-Meldung »Source Quench«

515

516

Routing-Fehler: ICMP & Expertendiagnose

Abb. 19.12: LANdecoder32: Router meldet »IMCP: Redirect«

Abb. 19.13: LANdecoder32: Die ICMP-Meldung »Redirect«

Kapitel 19 • Troubleshooting mit TCP/IP

517

Warnung Falle! Das Beispiel zeigt eine absolute Todesfalle: Der eine Router ist überlastet und sagt dem Host, er soll mal langsamer senden; der aber denkt sich: Na, nehme ich doch den anderen Router! Der aber weiß, dass er keinen direkten Zugang zu dem IP-Zielnetz hat, und verweist den Host - korrekt - wieder an den ersten Router. Fehler: Der Router ist überlastet (erstens); der WinNT-Server versteht die SourceQuench-Meldung nicht (zweitens). Expertendiagnose: Ein weiterer Hinweis kommt durch die »Expert Diagnosis«, die zeigt: IP-Pakete wurden lokal geroutet, also im selben LAN-Segment von einem Router zum anderen weitergereicht.

Abb. 19.14: LANdecoder32: Expertendiagnose der TCP/IP-Dialoge

Die fortgeschrittenen Analyzer wie Surveyor (Shomiti), LANdecoder32 (Triticom) und andere erkennen solche Ereignisse inzwischen automatisch.

518

19.4

Netzwerk langsam: Durchsatzmessung

Netzwerk langsam: Durchsatzmessung Problem: Der Datendurchsatz zum IP-Partner schwankt, aber die Verbindung steht. Es besteht der Verdacht, dass die Transitnetze zu sehr belastet sind. Anwender sagen: »Das Netzwerk ist langsam.« Diagnose: Spezielle Netzwerk-Tools testen den Datendurchsatz zu beliebigen IP-Rechnern, Netzwerk-Laufwerken, Servern. Beispiel: AnySpeed (PY Software, USA).

Abb. 19.15: AnySpeed misst permanent den Datendurchsatz im Netz

Am Kurvenverlauf bzw. an den Meldungen im Statusfenster lässt sich schnell ablesen, ob der Datendurchsatz auf einer Strecke deutlich abgesunken ist.

Kapitel 19 • Troubleshooting mit TCP/IP

19.5

519

IP-Pakete gehen verloren: Paketanalyse Problem: Der Datendurchsatz zum IP-Partner schwankt, aber die Verbindung steht. Die Applikation arbeitet langsam. Es besteht der Verdacht, dass IP-Pakete verloren gehen, da ein erstes Vor-Checking mit AnySpeed keinen Einbruch beim Datendurchsatz gezeigt hat. Diagnose: Protokoll-Analysatoren mit automatischen Auswertungsfähigkeiten (Expertendiagnose) können solche Vorkommnisse aufdecken. Erkennbar sind Paketverluste am leichtesten an den darauf folgenden Paketwiederholungen, sog. ReTransmissions. Im Detail bedeutet das, dass die Übertragung mehrfach an derselben Byte-Position im Datenstrom begonnen (bzw. wiederholt) wird; es werden also Daten gesendet, die bereits einmal übertragen worden waren. Bei TCP läuft das auf eine Analyse der TCP Sequence Number hinaus. Ähnliche Offset-Zähler sind in SPX, SMB, NCP enthalten. Beispiel: LANdecoder32 (Triticom, USA).

Abb. 19.16: LANdecoder: Expertendiagnose zu TCP-ReTx

520

Filter setzen auf IP und ARP

Abbildung 19.16 zeigt, dass ab TCP Sequence Number 32205102 erneut mit der Übertragung begonnen wird, obwohl bereits ab einer höheren Byte-Position, nämlich 32205128, gesendet worden war. Der Rücksprung auf die kleinere Zahl (also vorige Byte-Position) bedeutet, dass zu einer davor liegenden Stelle im Datenstrom zurückgesprungen werden musste, weil offensichtlich die ab dieser Stelle gesendeten Daten

19.6

•

beim Empfänger nicht angekommen waren oder

•

vom Empfänger nicht quittiert worden waren.

Filter setzen auf IP und ARP Problem: Es sollen alle TCP/IP-Pakete mitgelesen werden – aber nur diese, nicht die Daten fremder Protokolle. Vorgehensweise: Da IP immer über ein sog. EtherType-Feld läuft (sei es im Ethernet-MAC-Header, sei es im LLC-SNAP-Header), wird der Filter auf dieses Feld gesetzt. Entscheidend ist dabei jedoch: Es darf nicht nur auf IP gefiltert werden! Es muss immer auch zusätzlich an ARP gedacht werden: •

EtherType 0x0800 = IP

•

EtherType 0x0806 = ARP

Fehlen die ARP-Pakete, könnten ganze Folgen von Messdaten nicht mehr mit hinreichender Sicherheit auswertbar sein. Beispiel: LANdecoder32 (Triticom, USA). Die Filtermaske in Abbildung 19.17 definiert zwei Filter, einen für ARP, einen für IP. Es geht auch bequemer bei Analysatoren, die schlicht die Protokolle zur Auswahl anbieten und den Offset in den Paketen selber austesten. Das ist einfacher zu handhaben, belastet aber den Prozessor des Analyserechners. Ein von Hand eingestellter Offset-Filter ist etwas unhandlicher, dafür aber während der Datenaufnahme besser, weil der Analyzer weniger Prozessorzeit verbraucht (da er nicht zu »denken« braucht).

Kapitel 19 • Troubleshooting mit TCP/IP

Abb. 19.17: LANdecoder32: Filter auf IP und ARP

521

Kapitel 20 NetWare IPX, SPX, NCP

524

Man möge es dem Autor verzeihen, wenn nur wenige Worte den Novell-Protokollen IPX, SPX und NCP gewidmet werden. •

Layer 3 – IPX: Internetwork Packet Exchange

•

Layer 4 – SPX: Sequenced Packet Exchange

•

Layer 7 – NCP: NetWare Core Protocol

Dies sei erklärt: 1. Der Autor betreibt nun seit langen Jahren LAN/WAN-Analyse. Und das zentrale Faktum seiner Arbeit ist, dass Fehler selten NetWare oder Unix betreffen. Meistens stehen Probleme mit Windows oder mit aktiven Komponenten (Repeater, Switches, Router) im Zentrum. Die NetWare-Protokolle haben über lange Jahre praktisch keine Rolle gespielt. So fiel die Entscheidung, das Buch so anzulegen, dass es dort hilft, wo die meisten Probleme sind. Und das betrifft nun einmal kaum IPX, SPX, NCP. 2. Die NetWare-Protokolle IPX und SPX sind massiv auf dem Rückzug. Fast überall wird auf TCP/IP umgestellt. Dies geschieht auch in NetWare-LANs endgültig durch den Einsatz von NetWare 5. 3. Das Protokoll IPX ist von seiner Struktur her darauf angelegt, – erstens eher in LANs zu arbeiten als in WANS, – zweitens keine Auflösung von Netzwerk- zu MAC-Adresse zu benötigen. Während die IP-Adresse im lokalen Subnetz des Empfängers jedesmal noch in dessen MAC-Adresse aufgelöst werden muss, trägt der IPX-Header in jedem Paket neben der IPX-Netzwerk-Adresse auch die MAC-Adresse von Sender und Empfänger in sich. Somit entfallen die Auflösungen, die IP etwa via ARP kennt. Somit entfällt aber auch eine zentrale Fehlerkategorie. 4. Das Protokoll SPX arbeitet sehr ähnlich wie TCP. Wer das Kapitel »TCP/IP« gelesen hat, wird sich bei SPX schnell zurechtfinden. Die Merkmale und Parameter sind wirklich verblüffend verwandt. 5. Das Protokoll NCP als Client-Server-Protokoll ist wie SMB bei Microsoft selten selber Gegenstand eines Fehlers. Es sei auf die dem Buch beiligende CD-ROM verwiesen, die ausführliche Beschreibungen zu allen Protokollen enthält – so auch zu IPX und SPX. Wer also doch noch mit diesen älteren Protokollen arbeitet, wird sich hier schnell eine ganze Fundgrube an Dokumentation erschließen. Gleiches gilt natürlich auch für alle anderen Protokolle, die in diesem Buch beschrieben sind.

Kapitel 21 Windows Networking 21.1 21.2 21.3 21.4 21.5 21.6 21.7 21.8 21.9 21.10 21.11 21.12

NetBIOS NetBEUI/NBF NWLink – NetBIOS über NetWare-IPX NetBT – NetBIOS over TCP/IP Suchdienst/Browser WINS DHCP SMB/CIFS WinNT Server hat lange Antwortzeiten WinNT: Infektionen & Wilderei Windows-Tools zur Netzwerkdiagnose Registry-Analyse mit RegCheck

526 539 540 542 544 552 560 565 568 569 571 573

526

NetBIOS

In diesem Abschnitt soll nicht die Arbeit geleistet werden, die in vielen Büchern zum »Windows Networking« bereits geleistet wurde; er setzt vielmehr die Kenntnis der grundlegenden Begriffe und Architekturen voraus. Dieses Kapitel folgt zwei Zwecken:

21.1

•

Darstellung der Windows-Protokolle mit Blick auf die Analyse

•

Darstellung der wichtigsten Fehlerquellen

NetBIOS NetBIOS (Treiber-Datei: Netbios.sys) war ursprünglich eine reine ProgrammierSchnittstelle in den Anfängen der LAN-Kommunikation; später wurde zusätzlich ein Netzwerkprotokoll daraus, das zudem schließlich durch das Protokoll SMB (Server Message Block) ergänzt wurde, um Client-Server-Kommunikation zu unterstützen.

21.1.1 NetBIOS Namen WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\.. ..\Control\ComputerName ..\Control\ComputerName\ComputerName ..\Control\ComputerName\ActiveComputerName Listing 21.1: WinNT Registry-Einträge zum Computer-Namen

NetBIOS-Namen bezeichnen Computer, Benutzer, Server, Gruppen oder Domänen. Der Computer-Name sowie der Domain-Name, die beide in der WindowsSystemsteuerung (Netzwerk) eingegeben werden, sind NetBIOS-Namen. NetBIOS-Namen haben eine Länge von 16 Zeichen, wobei nur 15 Zeichen den eigentlichen Namen enthalten, während das letzte, das 16. Zeichen, den Ressourcen-Typ zum Namen bezeichnet (z.B. Computer-Name oder Domain-Name). Es wird dringend davon abgeraten, Sonderzeichen zu verwenden (obwohl einige zugelassen sind). Das Einfachste ist, die Regeln für MS-DOS Datei-Namen einzuhalten. Insbesondere wird gewarnt vor der Verwendung von Leerzeichen, Punkt (.) und Asterisk (*). Der Punkt kann als Bestandteil eines DNS-Namens, der Asterisk als Broadcast missverstanden werden (siehe auch: NetBIOS Scope ID).

Kapitel 21 • Windows Networking

527

Abb. 21.1: NetBIOS-Namen: Computer-Namen, Domänen-Name 16. Byte im NetBIOSNamen

Art des Namens (Einzel- oder Gruppenname)

Bedeutung, Verwendung

0x00

Computer-Name oder DomainName

NetBIOS Computer- oder Domänen-Name; Arbeitsstationsdienst

0x01

Gruppenname

Wird gelesen als: »_MSBROWSE_« Bezeichnet bei IP den lokalen Hauptsuchdienst, wird verwendet für die Meldung bei anderen Suchdiensten bzw. zur Suche des Master Browsers. Teilweise wird statt des Zeichens 0x01 »_ MSBROWSE_« im Klartext verwendet.

0x03

Computer-Name oder Benutzername

Wird an Computer- oder Benutzernamen gesendet; Nachrichtendienst

0x06

Computer-Name

RAS Server

Tab. 21.1: NetBIOS Namens- bzw. Ressourcen-Typen

528

NetBIOS

16. Byte im NetBIOSNamen

Art des Namens (Einzel- oder Gruppenname)

Bedeutung, Verwendung

0x1B

Domain-Name

Domain Master Browser (PDC)/Hauptsuchdienst

0x1C

Domain-Name

Gruppen-Name mehrer Domains; verwendet von PDC und BDC (bis zu 25 PDCs/BDCs je Gruppe)

0x1D

Domain-Name

Domain Master Browser (PDC) bzw. Hauptsuchdienst macht seine Suchlisten bei den Sicherungssuchdiensten bekannt; Suchdienst

0x1E

Domain-Name

Gruppen-Name für Broadcasts zwecks Auswahl des Hauptsuchdienstes; Suchdienst

0x1F

Computer-Name

NetDDE Service

0x20

Einzelname Gruppenname

Server-Dienst (Resource/Share Server); Gruppenname zur Verwaltung der Computer

0x21

Computer-Name

RAS Client

0xBE

Computer-Name

Network Monitor Agent

0xBF

Computer-Name

Network Monitor Server

Tab. 21.1: NetBIOS Namens- bzw. Ressourcen-Typen (Forts.)

Abbildung 21.2 zeigt ein NetBIOS-Paket mit einem Computer-Namen (Absender, Typ 0x00) und einem Domänen-Namen (Empfänger, Typ 0x1E); Abbildung 21.3 zeigt den Analyzer mit einer Liste vieler verschiedener NetBIOS-Pakete und Namens- bzw. Ressourcen-Typen, darunter auch »__MSBROWSE__«.

Abb. 21.2: NetBIOS-Paket mit Domain-Name und Ressourcen-Typ <1E>

Die Namenstypen können entweder am WINS-Server abgefragt werden oder am PDC mit dem Befehl nbtstat.

Kapitel 21 • Windows Networking

529

Abb. 21.3: NetBIOS-Pakete mit verschiedenen Namenstypen

21.1.2 NetBIOS-Namen: 16 Zeichen vs. 32 Zeichen (CIFS) Während in älteren Protokollvarianten der Name auf der Leitung nur mit 16 Zeichen im Klartext verwendet wird, benutzen neuere Protokollvarianten »mangled characters«, bei denen jedes ASCII-Zeichen in seine zwei Byte-Hälften zerlegt und jede Hälfe einem jeweils eigenen Byte zum Grundwert 0x41 (»A«) zuaddiert wird – das Ergebnis sind zwei neue Bytes (CIFS-Standards RFC 1001, 1002). Das folgende Beispiel verdeutlicht diesen Mechanismus: "T" = ASCII 84 = 0x54 = (0x41+0x05)&(0x41+0x04) = 0x4645 = "FE" "7" = ASCII 55 = 0x37 = (0x41+0x03)&(0x41+0x07) = 0x4448 = "DH" Listing 21.2: Die Umsetzung von 16-Byte-Namen in 32-Byte-Codierung

530

NetBIOS

Diese Namen sind nicht mehr im Klartext lesbar; hier ist man auf die Auflösung durch den Protokoll-Decoder angewiesen.

Abb. 21.4: Derselbe NetBIOS-Name mal mit 16 (oben), mal mit 32 Zeichen (unten) dargestellt

Abb. 21.5: Filter auf den in 32 Byte kodierten NetBIOS-Namen

Kapitel 21 • Windows Networking

531

In Abbildung 21.4 ist gut zu sehen, wie derselbe Computer-Name = NetBIOSName »NT700V03« mal in 16 Byte und mal in 32 Byte dargestellt ist. Das Filtern der 32-Byte-Namen ist möglich trotz der kryptischen Kodierung. Wenn man einen Analyzer hat, der den Hex-Code einer markierten Stelle automatisch in den Filter übernimmt, ist das kein Problem (siehe Abbildung 21.5).

21.1.3 NetBIOS Namensdienste: Broadcasts/WINS NetBIOS-Namen müssen im Netzwerk vollständig eindeutig sein; es dürfen nicht zwei Maschinen denselben Namen verwenden.

Abb. 21.6: NetBIOS-Broadcast zur Namensauflösung an die NetBIOS-Multicastbzw. Funktionsadresse MAC=0x030000000001

532

NetBIOS

Darum betreibt NetBIOS einigen Aufwand, die Eindeutigkeit der Namen zu sichern. Bei NetBEUI (LLC) und NWLink (IPX) wird das über Broadcasts durch die Gesamtheit aller NetBIOS-Teilnehmer erledigt; bei NetBT (TCP/IP) kann dies sowohl über Broadcast wie auch über Namens-Server (WINS) geschehen. Während sich bei NetBEUI und NWLink jeder NetBIOS-Rechner per Broadcast bei allen anderen bekannt macht (und andere per Broadcast sucht), melden sich unter TCP/IP die NetBIOS-Rechner (sofern sie als WINS-Client eingestellt sind) bei dem WINS-Server an (Namensregistrierung); bei diesem entsteht hierdurch eine Liste der NetBIOS-Rechner im Netz (bzw. in der Domain). Wenn alle NetBIOS-Maschinen als WINS-Clients eingestellt sind, hat der WINSServer notwendig die vollständige Liste aller NetBIOS-Teilnehmer.

Abb. 21.7: NetBIOS- bzw. WINS-Broadcasts über UDP-Port 137 an die IP Subnet Broadcast Address

Kapitel 21 • Windows Networking

533

Abbildung 21.6 zeigt einen alten, »klassischen« NetBIOS-Broadcast zur Namensauflösung (Name Query) auf Ethernet an die Multicast- und Funktionsadresse von NetBIOS-Stationen MAC=0x030000000001. Abbildung 21.7 zeigt einen WINS-Broadcast, gerichtet an die LAN Broadcast Address MAC=0xFFFFFFFFFFFF (hier nicht zu sehen) sowie die IP Subnet Broadcast Address IP=53.5.191.255 (abhängig vom Subnetz); die Dienstkennung ist der UDP-Port 137. Die WINS-Anfrage in Abbildung 21.7 findet über einen Broadcast statt, weil der Teilnehmer entweder keine IP-Adresse von WINS-Servern kennt, oder weil der Teilnehmer so eingestellt ist, dass WINS-Broadcasts vorgeschrieben sind – dies wird über den sog. WINS Knoten-Typ geregelt (siehe 21.6.6).

21.1.4 NetBIOS Suchdienste Zu den Namensdiensten bedarf es eines Suchdienstes, um andere NetBIOS-Teilnehmer finden zu können (Datei: Lmsvcs.exe). Bei NetBEUI (LLC) und NWLink (IPX) läuft das historisch über Broadcasts; später führte Microsoft den sog. Master Browser (Hauptsuchdienst) ein: Ein Rechner führt den Suchdienst für die anderen aus; diese können die Suchliste bei ihm beziehen. Unter NetBT (TCP/IP) und WinNT allgemein wird heute generell über einen Master Browser gearbeitet (immer der PDC); zudem wird empfohlen, über WINS zu arbeiten, um nicht via Master Browser gefundene NetBIOS-Namen dann doch per Broadcast in die IP-Adresse des NetBIOS-Rechners auflösen zu müssen. Der Master Browser wird bei Broadcasts und sog. Mailslot-Nachrichten mit dem Namen »__MSBROWSE__« identifiziert. Er meldet sich alle zwölf Minuten mit dieser Kennung.

21.1.5 NetBIOS Scope ID WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\.. ..\Services\NetBT\Parameters\ScopeId Listing 21.3: WinNT Registry-Einträge zur NetBIOS Scope ID

Die NETBIOS Scope ID bzw. die NetBIOS-Bereichskennung bildet NetBIOSGruppen bzw. Gruppen von NetBIOS-Rechnern; über die Gruppengrenze hinweg können diese nicht mehr kommunizieren (Closed User Groups). Das kann u.a. dazu führen, dass kein NetLogon auf Server möglich ist, die eine andere NetBIOS Scope ID haben. Ähnliches ist für die NetBIOS-Suchdienste zu erwarten.

534

NetBIOS

Technisch geschieht das so, dass bei Namensauflösungen dem NetBIOS-Namen die Bereichskennung als Erweiterung beigegeben wird. Ist die Bereichskennung z.B. »synapse.de«, und der Rechner heißt »Laptop_FF«, so würde daraus »Laptop_FF.synapse.de«. Die Ähnlichkeit zu DNS ist weder zufällig noch ungewollt. Darum sollten immer dort, wo DNS und NetBIOS Scope gleichzeitig verwendet werden, die DNSDomain und die NetBIOS Scope ID denselben Namen tragen. Warnung Wenn Sie NetBIOS-Scope nicht bereits verwenden oder wenn in Ihrem Netzwerk DNS eingesetzt wird, ist von einer Verwendung dringend abzuraten. Hier verbirgt sich eine Fehlerquelle ersten Ranges!

21.1.6 NetBIOS Nachrichtentypen Die Übertragungen von NetBIOS werden wie folgt unterschieden: •

Namesanforderung, -auflösung, -auswertung

•

verbindungslose Datagramme

•

Verbindungsorientierte Sitzungsdaten und Befehle

Den Befehls- bzw. Nachrichtentypen entsprechen verschiedene Protokollvarianten.

21.1.7 NetBIOS Protokollvarianten Namensauflösungen und -anmeldungen etc. werden als Broadcast gesendet: bei LLC über LLC-I, normal über IPX oder bei IP mittels UDP; eine Ausnahme stellt die Registrierung an einem WINS-Server dar. Verbindungslose Datagramme werden bei LLC über LLC-I geschickt, normal über IPX oder bei IP mittels UDP. Verbindungsorientierte Daten werden bei LLC über LLC-II geschickt, normal über IPX oder bei IP mittels TCP. Protokoll

Namensauflösung etc.

Verbindungslose Datagramme

Verbindungsorientierte Daten

NetBEUI

MAC-Broadcast*, LLC-I

MAC-Broadcast*, LLC-I

MAC-Adresse, LLC-II

NWLink

MAC-Broadcast, IPX

MAC-Broadcast, IPX

MAC-Adresse, IPX

NetBT

MAC-Broadcast, IP, UDP Port 137

MAC-Broadcast, IP, UDP Port 138

MAC-Adresse, IP, TCP Port 139

Tab. 21.2: Protokollvarianten: NetBIOS über ... (NetBEUI, NWLink, NetBT)

Kapitel 21 • Windows Networking

535

Bei den mit »Broadcast*« gekennzeichneten Hinweisen zur MAC-Adresse kann entweder die LAN-Broadcast-Adresse MAC=0xFFFFFFFFFFFF verwendet werden, oder die Meldungen werden an die Multicast- und Funktionsadresse von NetBIOS gesendet: MAC=0x030000000001 (nur NetBEUI). IP und IPX verwenden neben der LAN-Broadcast-Adresse noch eigene (Sub-) Netz-Broadcast-Adressen. Die Liste in Tabelle 21.2 ist nicht vollständig, sondern gibt lediglich eine Übersicht über die wichtigsten Kategorien; es gibt reichlich Varianten.

Abb. 21.8: NetBEUI Multicast-Adresse für NetBIOS MAC=0x030000000001

536

NetBIOS

21.1.8 NetBIOS-Bindungen Die Systemsteuerung (Netzwerk) zeigt an, welche NetBIOS-Varianten auf welche Adapter bzw. Protokolle gebunden sind.

Abb. 21.9: WinNT NetBIOS-Konfiguration

Abb. 21.10: WinNT – Systemsteuerung – Netzwerkdienste (1)

Kapitel 21 • Windows Networking

Abb. 21.11: WinNT – Systemsteuerung – Netzwerkdienste (2)

Abb. 21.12: WinNT – Systemsteuerung – Netzwerkdienste (3)

537

538

NetBIOS

Abbildung 21.9 zeigt folgende Bindungen von NetBT (NetBIOS over TCP/IP): •

NetBT über Adaptertreiber DLKFET (D-Link Fast Ethernet)

•

NWLinkNb über den Protokolltreiber NwLnkIpx (NetWare Link IPX)

•

NetBT über Adaptertreiber ACCNT (Accton Ethernet 10 Mbps)

Die Reihenfolge der NetBIOS-Bindungen, ausgedrückt in der LANA-Nummer, spielt beim NetBIOS-Suchdienst eine Rolle (siehe 21.5.4). In Abbildung 21.10, 21.11 und 21.12 sind diese Bindungen erneut zu sehen; hier werden im Gegensatz zum Fenster »NetBIOS-Konfiguration« jedoch alle Protokolle und Dienste angezeigt.

21.1.9 NetBIOS in der WinNT Registry Die folgende Liste der Registry-Einträge ist schon deswegen nicht vollständig, weil teilweise nur Teilschlüssel angegeben wurden ohne die darunter noch folgenden Unterschlüssel. Gleichwohl sind die angegebenen Registry-Schlüssel repräsentativ, weil die wichtigsten aufgeführt sind. NetBIOS/WinNT Registry (1): Registry-Schlüssel, die nicht per RegEdit etc. mutwillig verändert werden sollten (ohne Nennung der Unterschlüssel): HKEY_LOCAL_MACHINE\Software\.. ..\Microsoft\NetBIOS ..\Microsoft\NetBT ..\Microsoft\NetDDE\Paramenters\NetBIOS ..\Microsoft\NwlnkNb ..\Microsoft\Rpc\NetBIOS ..\Microsoft\Rpc\ClientProtocols ..\Microsoft\Rpc\ServerProtocols HKEY_LOCAL_MACHINE\System\CurrentControlSet\.. ..\Control\ComputerName ..\Enum\Root\LEGACY_NETBIOS ..\Enum\Root\LEGACY_NETBT ..\Enum\Root\LEGACY_NWLNKNB ..\Services\Browser ..\Services\EventLog\System\NetBIOS ..\Services\EventLog\System\NetBT ..\Services\EventLog\System\NwlnkNb ..\Services\LanManServer Listing 21.4: WinNT Registry-Einträge zu NetBIOS (1)/nicht zu editieren

Kapitel 21 • Windows Networking

539

..\Services\NetBIOSInformation ..\Services\NetBIOS ..\Services\Tcpip\ServiceProvider\NetBtPriority ..\Services\WinSock\Setup Migration\Providers\NetBIOS Listing 21.4: WinNT Registry-Einträge zu NetBIOS (1)/nicht zu editieren (Forts.)

NetBIOS/WinNT Registry (2): Registry-Schlüssel, die ggf. per RegEdit oder Systemsteuerung/Netzwerk verändert werden können (ohne Nennung der Unterschlüssel): HKEY_LOCAL_MACHINE\System\CurrentControlSet\.. ..\Services\Dhcp\Parameters\Options ..\Services\NBF\Parameters ..\Services\NetBT\Parameters ..\Services\NetBT\Adapters\AdapterName ..\Services\NwlnkNb\Parameters ..\Services\NwlnkIpx\NetConfig\Driver# Listing 21.5: WinNT Registry-Einträge zu NetBIOS (2)/änderbar

Die verschiedenen Registry-Schlüssel werden im Anhang A beschrieben.

21.2

NetBEUI/NBF WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\.. ..\Services\NBF\Parameters Listing 21.6: WinNT Registry-Einträge zu NBF/NetBEUI

Dies ist die historisch gesehen zweite NetBIOS-Variante; heute ist es die älteste der noch verwendeten Varianten (Treiber-Datei: Nbf.sys). Das NetBIOS Extended User Interface (NetBEUI) arbeitet mit dem sog. NetBIOS Framing Protocol (NBF) zusammen. Protokoll-Stapel: Layer 2 (MAC)

Layer 2b (DLC)

Layer 5 (Session)

Ethernet/Token-Ring

LLC-I (verbindungslos)

NetBIOS

Ethernet/Token-Ring

LLC-II (verb.orientiert)

NetBIOS

Tab. 21.3: Protokollstapel bei NetBEUI (NetBIOS-over-LLC)

540

NWLink – NetBIOS über NetWare-IPX

NetBEUI wird traditionell verwendet von Windows for Workgroups (WfW), Win95 und Win98; aus Gründen der Abwärtskompatibilität können auch WinNTRechner mit NetBEUI arbeiten. WinNT-PDCs, die für die NT-Domain sowieso als Hauptsuchdienst arbeiten, können ihre Suchlisten einem WfW/Win95/98-Suchdienstrechner zur Verfügung stellen. NBF bietet folgende Möglichkeiten des Nachrichten- und Datenaustauschs bzw. folgende Arten von Programmierschnittstellen (API: Application Programming Interfaces): •

NetBIOS

•

SMB Named Pipes

•

SMB Mailslots

•

NetDDE (Network Dynamic Data Exchange)

•

RPC (Remote Procedure Call) over NetBIOS

•

RPC over Named Pipes

Die Namensauflösung findet historisch statt ... •

per Broadcast im LAN

•

per LookUp im lokalen NetBIOS Name Cache

... und in jüngeren Konfigurationen auch über die Verwendung eines Hauptsuchdienstes/Master Browsers.

21.3

NWLink – NetBIOS über NetWare-IPX WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\.. ..\Services\NwlnkIpx\NetConfig\Driver# ..\Services\NwlnkNb\Parameters Listing 21.7: WinNT Registry-Einträge zu NWLink/NetBIOS-over-IPX

Dies ist die historisch gesehen jüngste NetBIOS-Variante (1995); sie macht NetBIOS WAN-fähig, da Router das IPX-NetBIOS übermitteln können.

Kapitel 21 • Windows Networking

541

Der Protokollstapel von NWLink ist ziemlich umfangreich: Layer 2a (MAC)

Layer 2b (DLC)

Layer 3

Layer 5 (Session)

Ethernet II (DIX)

IPX

NetBIOS oder NMPI

Ethernet

IPX

NetBIOS oder NMPI

Ethernet/Token-Ring

LLC

IPX

NetBIOS oder NMPI

Ethernet/Token-Ring

LLC + SNAP

IPX

NetBIOS oder NMPI

Tab. 21.4: Protokollstapel bei NWLink (NetBIOS-over-IPX)

Bei NMPI handelt es sich um das „Name Management Protocol over IPX“, eine NetBIOS-Erweiterung für IPX, die eine Art Source-Routing für IPX+NetBIOS ermöglicht.

Abb. 21.13: NetBIOS-Broadcast über Ethernet und IPX

542

NetBT – NetBIOS over TCP/IP

Um NetBIOS über bestimmte IPX-Routen senden zu können, wurde eine erweiterte Fassung des NetBIOS-Protokolls entwickelt, das NMPI (Name Management Protocol over IPX): •

Ethernet II (DIX) + IPX+ NMPI

•

Ethernet + IPX + NMPI

•

Ethernet/Token-Ring + LLC + IPX + NMPI

•

Ethernet/Token-Ring + LLC +SNAP + IPX + NMPI

NWLink wird traditionell verwendet in Netzwerken mit Novell NetWare; es wird das sowieso schon verwendete IPX (das für NetWare mit NCP arbeitet) zusätzlich mit NetBIOS genutzt. Abbildung 21.13 zeigt ein typisches NetBIOS-Paket, das über IPX transportiert wird. Sowohl Ethernet wie auch IPX enthalten die Endgeräte-Broadcast-Adresse 0xFFFFFFFFFFFF.

21.4

NetBT – NetBIOS over TCP/IP WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\.. ..\Services\AdapterName#\Parameters\Tcpip ..\Services\Dhcp\Parameters\Options\Option# ..\Services\DhcpServer\Parameters ..\Services\NetBT\Parameters ..\Services\NetBT\Adapters\AdapterName ..\Services\Tcpip\Parameters\ ..\Services\Tcpip\Parameters\PersistentRoutes ..\Services\Tcpip\ServiceProvider\NetBtPriority ..\Services\Tcpip\Parameters\Winsock Listing 21.8: WinNT Registry-Einträge zu NetBT/NetBIOS-over-TCP/IP

WinNT Tool: nbtstat.exe (Eingabeaufforderung, s.Kapitel "Windows Tools").

NetBT ist die historisch vorletzte NetBIOS-Variante (1993) und stellt heute den WinNT-Standard dar; sie macht NetBIOS WAN-fähig, da Router das IP-NetBIOS übermitteln können. NetBIOS-over-TCP (NetBT) wird auch kurz als NBT bezeichnet.

Kapitel 21 • Windows Networking

543

Der NetBT-Protokollstapel sieht wie folgt aus: Layer 2a (MAC)

Layer 2b (DLC)

Ethernet II (DIX) Ethernet/Token-Ring

LLC + SNAP

Layer 3

Layer 4

Layer 5

IP

UDP/TCP

NetBIOS

IP

UDP/TCP

NetBIOS

Tab. 21.5: Protokollstapel bei NetBT (NetBIOS-over-TCP/IP)

Da NetBIOS wesentlich von den Protokollen IP, UDP und TCP abhängt, muss bei einer Überprüfung von NetBIOS immer auch der gesamte Protokollstapel mit seinen Einstellungen gesehen werden: Zur entsprechenden Analyse von TCP/IP sei auf das entsprechende Kapitel verwiesen.

Abb. 21.14: NetBT: NetBIOS-Dialog über TCP an Service-Port 139

544

Suchdienst/Browser

Die verschiedenen Nachrichtentypen von NetBIOS werden wie folgt übertragen: Protocoll/Port

Anwendung

UDP Port 137

Namensdienste/WINS

UDP Port 138

verbindungsloses NetBIOS/Datagramme/Broadcasts

TCP Port 139

verbindungsorientiertes NetBIOS

Tab. 21.6: UDP-TCP Ports bei NetBIOS-over-IP

Datagramme, die über UDP Port 138 gesendet werden, enthalten NetBIOSNamen mit der Typenkennung 0x03. In Abbildung 21.14 ist ein herkömmlicher Dialog zu sehen über den »NetBIOS Session Port 139« von TCP. Die Computer-Namen bzw. NetBIOS-Namen von Sender und Empfänger sind deutlich zu sehen. Da NetBIOS die Teilnehmer über diese Namen identifiziert, hat zuvor eine Auflösung in die IP-Adresse der jeweiligen Gegenstelle stattgefunden.

21.5

Suchdienst/Browser WinNT Registry: HKEY_LOCAL_MACHINE\Software\.. ..\Microsoft\Browser HKEY_LOCAL_MACHINE\System\CurrentControlSet\.. ..\Enum\Root\LEGACY_BROWSER ..\Services\Browser\Parameters ..\Services\LanManServer\Parameters ..\Services\EventLog\System\Browser Listing 21.9: WinNT Registry-Einträge zu Suchdienst/Browser

WinNT Tools: browmon.exe, Browstat.exe (siehe Kapitel "Windows Tools").

System-Datei: Lmsvcs.exe. Die Frage der Namens- und Adressauflösung bzw. die Frage nach dem Ausfindigmachen eines NetBIOS-Rechners oder einer NetBIOS-Ressource ist eine Kernfrage bei allen NetBIOS-Varianten überhaupt.

Kapitel 21 • Windows Networking

545

21.5.1 Varianten der NetBIOS Namenstabellen NetBIOS-Namen können der MAC- oder IP-Adresse des Empfängers wie folgt zugeordnet werden: Namensquelle

Art

Kommentar

NetBIOS Name Cache

dynamisch

Der Name Cache ist eine dynamische Namenstabelle, die zur Laufzeit im Speicher geführt wird. Ist nur bei alten NetBEUI-LANs hinreichend vollständig aufgrund der ständigen NetBIOS-Broadcasts aller Teilnehmer.

NetBIOS Name Server (WINS)

dynamisch

WINS-Clients melden sich beim WINSServer an und fragen bei diesem nach, wenn sie eine Namens- bzw. Adressauflösung brauchen. Der WINS-Server führt die Tabellen.

LAN Broadcast bzw. IP/ IPX Subnet Broadcast

dynamisch

Diese Variante ist notwenig, wenn kein Name Server befragt werden kann. Das Ergebnis des Broadcasts ist im Erfolgsfalle ein neuer Eintrag im Name Cache des NetBIOS-Teilnehmers.

LMHOSTS (Datei)

statisch

Diese der Unix-Datei /etc/hosts nachempfundene Datei der LAN Manager Hosts kann alle Adressdaten enthalten, ist aber schwierig zu pflegen. Diese Variante ist kaum noch in Gebrauch.

HOSTS (Datei)

statisch

Diese den Unix-Systemen (/etc/hosts) entlehnte Datei kann verwendet werden, wenn IP-Host-Name und NetBIOS Computer-Name identisch sind. Diese Variante ist kaum noch in Gebrauch.

DNS Server

dynamisch

Als übergreifender Standard hat sich in WinNT-Netzen WINS durchgesetzt. Der Erfolg von Internet, Intranet und Extranet wirft jedoch wieder die Frage nach Vereinheitlichung auf. Windows 2000 wird voll auf DNS beruhen.

Tab. 21.7: Formen der NetBIOS Namensauflösung/Tabellen

546

Suchdienst/Browser

21.5.2 Der Hauptsuchdienst/Master Browser Um NetBIOS-Maschinen bzw. Ressourcen (Server, Freigaben/Shares) zu finden, läuft auf jedem Primary Domain Controller (PDC) der sog. Hauptsuchdienst (Master Browser). Für jede der oben beschriebenen Protokollvarianten von NetBIOS, allgemein NetBIOS Transport genannt, gibt es einen eigenen Suchdienst bzw. muss es einen eigenen Suchdienst geben. Der Master Browser wird in NetBIOS-Nachrichten identifiziert durch den Namen »__MSBROWSE__« (Eselsbrücke: das lässt sich lesen als »MicroSoft Browser«, aber auch als »MaSter Browser«). Im NetBIOS-Header ist die Verwendung von »__MSBROWSE__« typisch für NetBEUI und NWLink. Alle drei Varianten – also NetBEUI, NWLink und NetBT – versenden im SMB-Header Mailslot-Nachrichten an »MAILSLOT\BROWSE« (oder NetBT verwendet WINS). Der Master Browser meldet sich mit der Kennung »__MSBROWSE__« alle zwölf Minuten. Dieses Intervall kann über einen Registry-Eintrag verkürzt werden (Listing 21.10). Es ist wichtig zu wissen, dass »__MSBROWSE__« nicht nur in Namensdienstnachrichten über UDP-Port 137 arbeitet, sondern auch als NetBIOS-Datagramme über UDP-Port 138; in diesem Fall trägt NetBIOS einen SMB-Teil, der weitere Angaben enthält. Es ist daher nicht ganz richtig, Namensdienste allein dem UDP-Port 137 zuzuschreiben, da auf diese Weise auch UDP-Port 138 beteiligt ist. Darum ist es problematisch, mit einem Filter auf UDP-Port 137 oder 138 arbeiten zu wollen. Ein wilder Filter (»wild«: ohne Offset-Angabe) auf die Textfolge »MSBROWSE« hilft sehr viel besser und auch ohne Mühe. Gibt es mehrere Rechner, die einen Suchdienst betreiben (können), und ist nicht von vornherein klar, welche Maschine den Hauptsuchdienst hat, so wird der Hauptsuchdienst (bzw. die Maschine, die ihn betreibt) zwischen den infrage kommenden Maschinen ausgehandelt. Hierzu kann jede Maschine, die entsprechend eingestellt ist, eine Browser-Wahl starten.

Kapitel 21 • Windows Networking

547

Abb. 21.15: NetBIOS-Datagramm mit SMB an UDP-Port 138 an den Empfänger »__ MSBROWSE__«

WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\.. ..\Browser\Parameters\MaintainServerList ..\Browser\Parameters\IsDomainMasterBrowser ..\Browser\Parameters\BackupPeriodicity ..\LanManServer\Parameters\Lmannounce Listing 21.10: WinNT Registry-Einträge zum Hauptsuchdienst/Master Browser

548

Suchdienst/Browser

Diese Registry-Einträge haben folgende Bedeutung: ..\Parameters\..

Bedeutung/Entstehung des Eintrages/Wirkung

MaintainServerList

Yes/No/Auto. Steht der Wert auf YES oder AUTO, wird WinNT beim Booten auch den Browser-Dienst starten. Bei YES wird eine Browser-Wahl gestartet; bei AUTO (dem VorgabeWert) geht der WinNT-Rechner in Wartestellung und beteiligt sich ggf. an einer Browser-Wahl. Bei NO wird der WinNT-Rechner niemals Hauptsuchdienst werden.

IsDomainMasterBrowser

Yes (True)/No (False). Dieser Wert wird dynamisch gesetzt. Bei YES ist der WinNT-Rechner, auf dem dieser Eintrag gegeben ist, der Domain Master Browser, also der Betrieber des Hauptsuchdienstes.

BackupPeriodicity

(DWORD – Zahlenwert) Der Wert steht für die Anzahl von Sekunden, die zwischen den Suchdienst-Bekanntmachungen des WinNT-Rechners liegen, sofern er Hauptsuchdienst in Wartestellung ist. Dieses Intervall liegt per Vorgabe-Wert bei 720 Sekunden = 12 Minuten.

Lmannounce

(DWORD – Zahlenwert) Der Wert steht für die Anzahl von Sekunden, die zwischen den Suchdienst-Bekanntmachungen des WinNT-Rechners liegen, sofern er Master Browser ist. Dieses Intervall liegt per Vorgabe-Wert bei 720 Sekunden = 12 Minuten. Dieser Registry-Eintrag wird in vielen Quellen, teilweise sogar Microsoft-Literatur, statt als »Lmannounce« als »Announce« bezeichnet – dies ist ein Fehler, der sich leider in viele andere Publikationen übertragen hat.

Tab. 21.8: Einträge in der WinNT-Registry zum Hauptsuchdienst

21.5.3 Je NetBIOS-Transport ein Suchdienst Dieser Hauptsuchdienst läuft für jede der genannten NetBIOS Protokollvarianten getrennt. Der Zugriff auf die Suchdienstliste des einen Master Browsers (z.B. von NetBEUI) hilft nicht, wenn ein gesuchter NetBIOS-Teilnehmer über ein anderes Protokoll arbeitet (z.B. NetBT) und somit in einer anderen Suchdienstliste steht.

21.5.4 Reihenfolge der Protokollbindungen zählt Es gibt Funktionen des Computer-Suchdienstes, die jeweils nur über die erste Bindung von NetBIOS-Transport an LAN-Adapter arbeiten.

Kapitel 21 • Windows Networking

549

Der Umstand alleine, dass sämtliche Rechner im Windows-Netzwerk dieselben Protokollbindungen aufweisen (NetBEUI, NWLink, NetBT), besagt noch lange nicht, dass sie sich auch alle »sehen«: Wenn die Reihenfolge der Adapter- bzw. Protokollbindungen nicht auf allen Rechnern identisch ist, werden sich nicht alle NetBIOS-Teilnehmer »sehen« können – zumindest nicht sofort, ggf. erst nach max. zwölf Minuten. So geschieht es immer wieder unter diesen Bedingungen, dass ein anderer NetBIOS-Rechner (bzw. dessen Freigabe) nicht im Windows Explorer bzw. in der Netzwerk-Umgebung auftaucht – um dann aber doch mit der Funktion »Start/ Suchen/Computer« gefunden zu werden. Ist dieses Phänomen zu beobachten (bzw. beklagen sich Anwender hierüber), so müssen die Adapter- bzw. Protokollbindungen auf sämtlichen Rechnern in dieselbe Reihenfolge gebracht werden. Hinweis auf Fehler im Suchdienstverhalten Mit dem Analyzer lassen sich Hinweise zu Fehlern dieser Art finden; am ehesten noch erreicht man dies z.B. durch das Setzen eines Filters auf »MSBROWSE« oder durch das Setzen eines Filters auf Broadcasts.

Abb. 21.16: Unterschiedliche Reihenfolge der Bindungen wird in den Broadcasts sichtbar

550

Suchdienst/Browser

Die Abbildung 21.16 zeigt dasselbe Ereignis drei Mal: •

Im oberen Fenster zeigt der Analyzer das jeweils höchste Protokoll im Paket – das ist teilweise NetBIOS, teilweise SMB.

•

Im mittleren Fenster zeigt der Analyzer das NetBIOS-Protokoll mit der Kennung »__MSBROWSE__«. Der erste Rechner mit MAC=0x0080036-69A302 sucht mit allen Paketen nach dem Rechner mit dem NetBIOS-Namen »IGR013«. Der zweite Rechner mit MAC=0x0006097-239878 sucht mit allen Paketen nach dem Rechner mit dem NetBIOS-Namen »K01860«.

•

Im unteren Fenster zeigt der Analyzer das Trägerprotokoll von NetBIOS (LLC und IPX).

Die Reihenfolge der Protokollstapel ist nun aufschlussreich: 1. Der erste Rechner mit mit MAC=0x080036-69A302 sucht – zuerst über IPX Paket-Typ 20 (WAN Broadcast) via LAN-Broadcast, – dann über IPX Paket-Typ 04 (Packet Exchange) via LAN-Broadcast, – zuletzt über LLC-I (UI) via LAN-Multicast an MAC=0x030000000001. 2. Der zweite Rechner mit MAC=0x0006097-239878 sucht – zuerst über LLC-I (UI) via LAN-Multicast an MAC=0x030000000001, – dann über IPX Paket-Typ 04 (Packet Exchange) via LAN-Broadcast. Eine Suche über IPX-WAN-Broadcast führt der zweite Rechner nicht durch. Es wird offensichtlich, dass beide Rechner nicht identisch suchen. Es ist daher möglich, dass bei solchen Ereignissen - zumal dann, wenn die Unterschiede noch größer sind - die verschiedenen Rechner nicht auf dieselben Suchdienste bzw. Suchdienstrechner treffen; und da die Suchdienste nach Protokollvarianten getrennt geführt werden, können sich ihre Inhalte bzgl. der Computer- bzw. NetBIOS-Namen erheblich unterscheiden. Das Erlebnis, einen anderen NetBIOS-Rechner zwar nicht im Windows Explorer zu sehen, ihn aber über »Start/Suchen/Computer« oder über einen eingerichteten Laufwerksbuchstaben dann doch zu sehen, ist u.a. hierauf zurückzuführen.

21.5.5 Viele Suchdienst-Server/Sicherungssuchdienst Der Master Browser (PDC) kann seine Suchdienstlisten an Rechner senden, auf denen ein Sicherungssuchdienst läuft (BDCs). Zwischen dem Hauptsuchdienst und den Sicherungssuchdiensten ist insbesondere unter WAN-Bedingungen eine Arbeitsteilung möglich und sinnvoll.

Kapitel 21 • Windows Networking

551

21.5.6 Suchdienstwahl: Wer ist Master Browser? Stehen mehrere Suchdienst-Server zur Verfügung, wird der Hauptsuchdienst-Server durch ein Wahlverfahren auf Protokollebene bestimmt; diese Wahl des Master Browsers erfolgt über Broadcasts (im LAN bzw. IP/IPX Subnetz) mit dem NetBIOS-Namen des jeweiligen WinNT-Servers nach der NetBIOS-Namens-Konvention <1E>; WINS wird hierbei nicht verwendet. Gibt es mehrere Suchdienst-Server, so gleichen sie untereinander ab, wer Vorrang hat; der Rechner mit der höchsten Priorität übernimmt den Hauptsuchdienst. NetBIOS-Maschine

Kennung

Betriebssystem

0xFF000000

Windows for Workgroups (WfW), Win95, Win98

0x01000000

Windows NT Workstation

0x10000000

Windows NT Server

0x20000000

Wahlversion

0x00FFFF00

Versionskriterien

0x000000FF

PDC

0x00000080

WINS System

0x00000020

Bevorzugter Hauptschlüssel

0x00000008

Aktueller Hauptsuchdienst

0x00000004

Eintrag MaintainServerList=Yes

0x00000002

Aktueller Sicherungssuchdienst

0x00000001

Tab. 21.9: Reihenfolge der Kriterien für eine Suchdienstwahl

Der aktuelle Master Browser kann bei WinNT mit folgendem Befehl abgefragt werden: browstat getmaster <domain_name>

Anstelle von wird die Abkürzung für den Protokolltreiber angegeben (etwa (NetBT_Lance1), an Stelle von <domain name>) der Name der WinNTDomäne, dessen Master Browser gesucht wird.

21.5.7 Namens-Datagramme via UDP Port 137 Datagramme zur Namensauflösung, die an UDP Port 137 gesendet werden (NetBT), werden normalerweise von Routern nicht weitergeleitet.

552

WINS

Wird dies an den Routern so geändert, dass sie NetBIOS Name Service Messages via UDP Port 137 doch in alle Subnetze vermitteln, erscheinen dem jeweiligen Anwender alle Ressourcen/Freigaben/Shares so, als lägen sie in einem einzigen lokalen Netzwerk-Segment; allerdings kann im schlechtesten Falle das Netz erheblich mit Broadcasts geflutet werden.

21.5.8 »MSBROWSE«-Datagramme an UDP Port 138 NetBIOS- und SMB-Pakete, die den NetBIOS-Namen »MSBROWSE« beinhalten (Hauptsuchdienst), laufen über UDP-Port 138.

21.6

WINS WINS (Windows Internet Name Service) ist sehr mit DNS verwandt, dem Domain Name Service des Internets; wer DNS kennt, wird viele Elemente bei WINS wiederfinden.

Abb. 21.17: Gestarteter WINS-Dienst am WinNT Server

Der WINS-Dienst muss aktiviert sein um beim Starten des WinNT-Servers geladen zu werden. In Abbildung 21.18 ist das Hauptfenster des WINS-Managers zu sehen; Abbildung 21.19 zeigt die Detailinformation zum Betrieb des WINS-Managers.

21.6.1 WINS statt Broadcasts Das Finden von Rechnern bzw. Ressourcen innerhalb der Gesamtheit aller NetBIOS-Teilnehmer über den Master Browser bzw. den Hauptsuchdienst-Server erspart dem Netzwerk schon viele Broadcasts – doch bleibt dieser Nutzen begrenzt, wenn der eine NetBIOS-Teilnehmer, der gerade einen anderen via

Kapitel 21 • Windows Networking

553

Suchdienstliste gefunden hat, diesen anderen via Broadcast rufen muss, weil ihm zu dessen NetBIOS-Namen die MAC-Adresse (NetBEUI), IPX-NetzwerkAdresse (NWLink) oder IP-Adresse (NetBT) fehlt.

Abb. 21.18: WinNT WINS-Manager/Hauptfenster

Abb. 21.19: WinNT WINS-Manager Detailinformation

554

WINS

Weiterhin soll den NetBIOS-Stationen abgewöhnt werden, sich ständig per Broadcast im Netz bekannt zu machen – was notwendig ist (war), um die Eindeutigkeit der NetBIOS-Namen sicherzustellen.

21.6.2 NetBIOS-Registration am WINS-Server Bei NetBIOS über TCP/IP erledigt dies der WINS-Server: Er führt eine Liste aller NetBIOS-Teilnehmer, ihres Ressourcen-Typs (siehe Tabelle 21.1) und ihrer IP-Adressen; er kennt zudem die Zugehörigkeit zur jeweiligen Workgroup (WfW, Win95, Win98) oder zur jeweiligen Domain (WinNT). Dies setzt voraus, dass sich jeder NetBIOS-Teilnehmer bei ihm meldet, wenn dieser gerade eingeschaltet wurde und die Protokolltreiber lädt.

Abb. 21.20: WinNT WINS-Manager Zeiteinstellungen

Dieser Vorgang der Anmeldung am WINS-Server wird WINS-Registration genannt. Der WINS-Server bestätigt gegenüber dem WINS-Client diese Registration; der WINS-Client muss sie in festen Abständen wiederholen, da jeder Registration nur eine beschränkte Lebenszeit zugeordnet ist.

21.6.3 Der WINS-Server kennt alle NetBIOS-Ressourcen Der WINS-Server kennt (und beantwortet Fragen nach): •

Computer-Name

•

Benutzername

Kapitel 21 • Windows Networking

•

Freigabename

•

Workgroup-Name

•

Domain-Name

555

Somit kann der WINS-Server z.B. nach der IP-Adresse eines per Freigabe öffentlichen Verzeichnisses gefragt werden (was natürlich auf die IP-Adresse des Rechners hinausläuft, auf dem die freigegebene Ressource liegt).

Abb. 21.21: WinNT WINS-Manager Datenbank/WINS-Clients

21.6.4 Mehrere WINS-Server/Replikationen Es gibt jeweils einen Primary WINS Server, der die zentrale Verwaltung der Datenbank zur Aufgabe hat; daneben kann es Secondary WINS Server geben, die einerseits bei Ausfall des ersten WINS-Servers dessen Arbeit übernehmen, die aber zudem als sog. Push- und Pull-Partner arbeiten können. Der erste WINS-Server läuft üblicherweise auf dem BDC, ein zweiter WINS-Server auf dem PDC. Die verschiedenen WINS-Server können ihre Tabellen austauschen und auch über Router hinweg zusammenwirken. Somit können Replikationen der WINS-Tabellen im Netzwerk auf verschiedene Rechnern verteilt werden. Abbildung 21.22 und Abbildung 21.23 zeigen die Bekanntmachung eines zweiten WINS-Servers (hier: dem PDC) beim Primary WINS Server (hier: dem BDC).

556

WINS

Abb. 21.22: WinNT WINS-Manager: WINS-Server hinzufügen

Abb. 21.23: WinNT WINS-Manager/Replikationspartner

Damit ist zudem sichergestellt, dass Namens- und Adressauflösungen auch in großen Netzen möglich ist, und zwar ohne die Übertragung von IP-Broadcasts über Router hinweg (siehe 21.5.7).

21.6.5 Voraussetzungen für erfolgreichen WINS-Einsatz Das alles aber sichert immer noch keinen Rückgang der Broadcasts, die NetBIOS zur Namensauflösung sendet. Damit die Broadcasts endgültig der Vergangenheit angehören, müssen folgende Bedingungen gegeben sein: •

Es gibt für alle NetBT-Clients mindestens einen erreichbaren WINS-Server.

•

Alle NetBT-Clients kennen die IP-Adressen mindestens eines WINS-Servers; dies wird am besten durch DHCP erreicht.

•

Alle NetBT-Clients sind darauf eingestellt, den/die ihnen bekannten WINSServer auch zu benutzen, anstatt weiter mit Broadcasts zu arbeiten. Die entsprechende Einstellung ist der sog. WINS Knoten-Typ; auch dieser wird am besten durch DHCP mitgeteilt.

Kapitel 21 • Windows Networking

557

•

Alle NetBT-Clients brauchen folglich mindestens einen erreichbaren DHCPServer, der die gesamten Konfigurationen korrekt enthält und auf Anfrage zurückgibt – dies geschieht in der Boot-Phase der IP/DHCP-Clients.

•

Alle NetBT-Clients müssen darum lokal so eingestellt sein, dass sie beim Laden des IP-Treibers per DHCP nach ihren Konfigurationsdaten fragen.

Der Kern der WINS-Effizienz ist mit Blick auf die Broadcasts daher beim sogenannten WINS Knoten-Typ gegeben.

21.6.6 Der WINS Node Type/Knoten-Typ WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\.. ..\Services\NetBT\Parameters\DhcpNodeType ..\Services\NetBT\Parameters\NodeType Listing 21.11: WinNT Registry-Einträge zum WINS Node Type/Knoten-Typ

WINS unterscheidet folgende Typen von WINS-Clients, Knoten-Typen genannt: Node Type

Code

Technik der NetBIOS-Namensauflösung

B-Node

0x01

Broadcast Node – nur Broadcasts an alle NetBT-Teilnehmer.

P-Node

0x02

Peer to Peer Node – nur direkte Abfrage beim WINS-Server.

M-Node

0x04

Mixed (Mode) Node – gemischt: Erst erfolgt ein Versuch durch Broadcasts (B-Node); erst wenn dies ohne Erfolg bleibt, erfolgt eine Anfrage beim WINS-Server (P-Node). Dieses Verfahren ist in aller Regel nur sinnvoll in Netzen, in denen nur eine Minderzahl der NetBT-Clients auch zugleich WINSClient ist – was letztlich immer früher oder später Broadcasts erzwingt.

H-Node

0x08

Hybrid (Mode) Node – gemischt: Erst erfolgt eine Anfrage beim WINS-Server (P-Node); wenn dies ohne Erfolg bleibt (weil es keinen WINS-Server gibt, oder weil der WINS-Server nicht helfen konnte), werden Broadcasts gesendet (B-Node). Wird im B-Node-Zustand nach zunächst fehlendem WINS-Server dann doch wieder einer gefunden, wechselt der NetBIOS-Teilnehmer wieder in den P-Node-Status.

Tab. 21.10: WINS Node Type – Knoten-Typen

Der in Tabelle 21.10 genannte Code für die Knoten-Typen wird von DHCP verwendet und entsprechend beim DHCP-Server für die IP-NetBT-Clients eingestellt.

558

WINS

In der Registry gibt es zwei Einträge, die den Knoten-Typ festlegen (können): NetBT\Parameters\NodeType und NetBT\Parameters\DhcpNodeType. Beide sind nicht von vornherein in der Registry vorhanden. NetBT\Parameters\

Bedeutung/Entstehung des Eintrages/Wirkung

DhcpNodeType

Der Schlüssel DhcpNodeType wird nur bei DHCP-Clients gesetzt, die einen entsprechenden Wert von DHCP-Server zugewiesen erhalten.

NodeType

Der Schlüssel NodeType kann manuell oder durch ein Konfigurationsprogramm in die Registry gesetzt werden. Ist er nicht vorhanden und wird der Knoten-Typ nicht duch DhcpNodeType gesetzt, arbeitet NetBT mit dem Knoten-Typ 0x00 = BNode (Broadcasts). Sind sowohl DhcpNodeType wie auch NodeType in der Registry vorhanden, geht der Wert von NodeType (sofern gültig, also ein Wert aus 0x01, 0x02, 0x04, 0x08) dem Wert von DhcpNodeType vor.

Tab. 21.11: Einträge in der WinNT-Registry zum WINS Knoten-Typ

Win95/98-Rechner können zum Knoten-Typ befragt werden über das Programm C:\WINDOWS\WINIPCFG.EXE (siehe Abbildung 21.24).

Abb. 21.24: Win95/98: Das Programm WINIPCFG.EXE zeigt den Knoten-Typ an, hier: »Broadcast« für B-Node.

Kapitel 21 • Windows Networking

559

21.6.7 WINS-Registry-Einträge beim Client WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\.. ..\Services\NetBT\Parameters\BcastQueryTimeout ..\Services\NetBT\Parameters\BroadcastAddress ..\Services\NetBT\Parameters\CacheTimeout ..\Services\NetBT\Parameters\DhcpNodeType ..\Services\NetBT\Parameters\DhcpScopeId ..\Services\NetBT\Parameters\InitialRefreshTimeout ..\Services\NetBT\Parameters\NameServerPort ..\Services\NetBT\Parameters\NameSrvQueryCount ..\Services\NetBT\Parameters\NameSrvQueryTimeout ..\Services\NetBT\Parameters\NodeType ..\Services\NetBT\Parameters\RefreshOpCode ..\Services\NetBT\Parameters\ScopeId ..\Services\NetBT\Parameters\Size ..\Services\NetBT\Parameters\WinsDownTimeout Listing 21.12: WinNT Registry-Einträge zu WINS beim WinNT Client

21.6.8 Bekannte WINS-Fehler Es gibt zwei Fehler, die in 1998/1999 dem Autor mehrfach begegnet sind; beide sind geeignet, das Netzwerk zu stören.

21.6.9 WINS-Knoten-Typ stimmt nicht Es ist ein bekanntes Problem bei Win95-Rechnern, dass sie trotz Einstellung auf H-Node als B-Node arbeiten. Am stärksten tritt dieses Problem bei DFÜ-Verbindungen auf: Wer sich mit seinem Rechner z.B. zu Hause direkt ins Internt einwählt, kann Folgendes mit dem Analyzer messen: Der Rechner ruft laufend ins Internet hinaus und versucht, via WINS-Broadcasts nach allen Maschinen zu suchen, die er so kennt. Manchmal kommt dieser Fehler auch bei WinNT 4 vor.

21.6.10 WINS-Server mit zerstörten Tabellen Im Sommer 1999 hatten verschiedene Kunden Probleme mit WINS-Servern. Es stellte sich heraus, dass die WINS-Server bei Client-Anfragen u.a. defekte NetBIOS-Namen zurückgaben, zum Teil völlig verstümmelt, und - was allein schon ein für sich sprechendes Faktum ist - angereichert mit ansonsten nicht verwendeten Sonderzeichen.

560

DHCP

Die WINS-Server wurden jeweils neu aufgesetzt; dann lief es (zunächst) wieder. Bei Microsoft konnte der Autor zu dem Problem nichts finden.

21.6.11 WINS und DNS: Siamesische Zwillinge Oft ist Folgendes zu beobachten: Wenn eine WINS-Auflösung nicht erfolgreich war, veranlasst der WINS-Prozess den DNS-Treiber, es doch auch einmal zu versuchen – und umgekehrt. Selbst ein Abschalten von WINS und/oder DNS kann das nicht zuverlässig verhindern. Diese Eigenmächtigkeit der Treiber resultiert aus dem Bemühen von Microsoft, Netzwerk-Ressourcen durch jede nur denkbare Namens- und Adressauflösung im Hintergrund zu erleichtern bzw. zu ermöglichen. Diese durchaus achtenswerte Grundidee, dem Anwender eine möglichst pflegeleichte Technik zu bieten, schlägt dann aber in ihr Gegenteil um, wenn bei diesem Vorgang sogar WAN-Leitungen angewählt und völlig fremde Rechner im Internet nach Namen gefragt werden, die sie bestimmt nichts angehen! Hier öffnet sich nicht nur ein Sicherheitsrisiko der schlimmsten Art – hier ist auch eine Kostenfalle, sofern nicht Standleitungen verwendet werden, bei denen das übertragene Datenvolumen sowie die Sendedauer keine Rolle (mehr) spielen.

21.7

DHCP In Abschnitt 21.6.5 wurde deutlich, dass die Verwendung von DHCP wesentlich bedingt, ob die NetBIOS-Namensdienste einwandfrei laufen. Um eine vollständige Liste aller Konfigurationsoptionen und Protokollparameter von DHCP zu sehen, schlagen Sie bitte im Kapitel 16 »TCP/IP« unter dem Abschnitt 16.10.2 »DHCP« nach.

21.7.1 DHCP-Optionen für WINS: Die sieben Todsünden Hier soll gezeigt werden, worauf es ankommt, damit NetBIOS bei NetBT eine korrekte Namensauflösung via WINS betreibt. Es sollen auch die schlimmsten Todsünden der DHCP-Konfiguration gezeigt werden.

21.7.2 DHCP-Fehler Nr. 1: IP Endadresse = 255!? Es ist ein kleiner Fehler im DHCP-Manager, dass er als sog. Endadresse eine IPAdresse zulässt, die der IP Broadcast Address im jeweiligen IP Subnet entspricht. Es ist manuell eine Korrektur nachzutragen, damit statt .255 nur .254 als letzte IPAdresse verwendet wird. Im gegebenen Beispiel - siehe Abbildung 21.25 - wäre das statt 192.168.111.255 die Adresse 192.168.111.254.

Kapitel 21 • Windows Networking

561

Abb. 21.25: DHCP Manger/IP-Endadresse = IP-Broadcast-Adresse .255

Wenn dies nicht korrigiert wird und wenn an einen IP-Client diese Endadresse .255 herausgegeben wird, können schlimmste Fehler und Wechselwirkungen auftreten: •

Bei jedem IP Subnet Broadcast anderer Maschinen wird sich diese eine angesprochen fühlen.

•

Wenn sie selber mit anderen sprechen will, müssten diese wiederum als IP Destination Address eine Adresse verwenden, die sie als IP Subnet Broadcast Address kennen – und entweder weigern sie sich, oder die Antworten an die falsch eingestellte Station werden wiederum von allen anderen mitgelesen.

Die Wechselwirkungen eines solchen Szenarios sind nicht vorherzusagen.

21.7.3 DHCP-Fehler Nr. 2: Knoten-Typ = 0x00 Warnung Falle! Wenn schon Standardwerte eingegeben werden, dann aber richtig!

562

DHCP

Abb. 21.26: DHCP-Manager: Standardwert für den WINS Node Type

Es bietet sich an, zunächst einen Standardwert für den WINS Knoten-Typ zu setzen. Allerdings: Der in Abbildung 21.26 gezeigte Knoten-Typ 0x01 sollte genau nicht gewählt werden, weil sonst jede Namensauflösung oder -bekanntmachung über Broadcasts abläuft!

21.7.4 DHCP-Fehler Nr. 3: Kein Standardwert Warnung Falle! Den Knoten-Typ aber gar nicht als Standard zu definieren (und zwar als 0x08 = H-Node), ist auch gefährlich – denn wenn gar kein Knoten-Typ festgelegt wird, arbeiten die DHCP-Clients von sich aus grundsätzlich mit Knoten-Typ 0x01! Und dann sind alle die Broadcasts wieder da (immer noch da), die man doch eigentlich mit WINS loswerden wollte. Ohne den richtigen Knoten-Typ aber nutzt das ganze WINS nichts. In Abbildung 21.27 ist zu sehen, wie völlig korrekt neben der Option 0x44 (WINS Server) auch die Option 0x46 (WINS Node Type) gewählt wurde.

21.7.5 DHCP-Fehler Nr. 4: 0x44 – ja/0x046 – nein!? Bei vielen DHCP-Servern ist zu beobachten, dass zwar die Option 0x44 gewählt und WINS-Server mit ihrer IP-Adresse angegeben wurden – das aber reicht nicht! Denn ohne Rückgabe des Knoten-Typs an die DHCP-Clients werden diese gnadenlos mit Knoten-Typ 0x00 arbeiten!

Kapitel 21 • Windows Networking

563

Abb. 21.27: DHCP-Manager/Bereichsoptionen 0x44 (WINS-Server) und 0x46 (WINS Node Type)

Abb. 21.28: DHCP-Manager/Bereichsoption 0x44/Angabe der IP-Adressen von WINS-Servern

Abbildung 21.28 zeigt, dass der erste sowie der zweite WINS-Server angegeben sind; somit sollte das WINS-System gegenüber Störungen robust gewappnet sein.

564

DHCP

21.7.6 DHCP-Fehler Nr. 5: Lokale WINS-Server angeben Warnung Falle! Achten Sie darauf, wo die WINS-Server stehen bzw. welchen DHCP-Clients Sie diese Rückgaben geben wollen! Wenn Sie über WAN-Leitungen arbeiten und in den Niederlassungen über eigene WINS-Server verfügen, sollten Sie unbedingt dafür sorgen, dass die dortigen Clients auch die dortigen WINSServer verwenden.

21.7.7 DHCP-Fehler Nr. 6: LANs ohne WINS-Server!? Warnung Falle! Das setzt natürlich voraus, dass Sie in den Niederlassungen überhaupt WINS-Server haben. Das darf beim Netzwerk-Design niemals übersehen werden.

21.7.8 DHCP-Fehler Nr. 7: Knoten-Typ 0x08 oder 0x00!? Warnung Falle! Sollte es in den Niederlassungen keine WINS-Server geben, ist unbedingt darauf zu achten, dass den dortigen Clients dann doch der Knoten-Typ 0x01/ B-Node (oder wenigstens 0x04/M-Node) gegeben wird, damit Namensauflösungen ggf. im dortigen Subnetz lokal per Broadcast stattfinden – und nicht durch WINS-Rufe über die langsamen WAN-Leitungen.

21.7.9 DHCP-Fehler Nr. 8: Server-Standort!? Warnung Falle! Aber auch dieses hängt davon ab, mit wem die dortigen Clients kommunizieren! Wenn die auswärtigen Clients in den Niederlassungen nur mit Servern in der Hauptstelle sprechen, nutzen NetBIOS-Broadcasts nur, wenn sie auch über die Router und die WAN-Leitungen in die Hauptstelle übertragen werden – was sehr unschön ist. Am Ende könnte sich ggf. anbieten, sog. WINS Proxy Server zu installieren, die Broadcasts mit NetBIOS-Namensanfragen beantworten können.

Kapitel 21 • Windows Networking

565

Abb. 21.29: DHCP-Manger/Bereichsoptionen/IP-Adressen für WINS-Server

Abb. 21.30: DHCP-Manager/Hauptfenster mit Optionsanzeige

Abbildung 21.30 zeigt, dass im Beispiel korrekt der WINS Knoten-Typ 0x08/HNode eingestellt wurde. Aber – wie gesagt: Auch das kann im Einzelfall falsch sein und muss vor der Eingabe geprüft werden!

21.8

SMB/CIFS

21.8.1 Client-Server-Protokoll Die Funktionalität von NetBIOS hat für die Client-Server-Welt der WindowsNetze schon früh nicht mehr ausgereicht. Mit SMB wurde ein umfangreiches Client-Server-Protokoll entwickelt, das alle Funktionen übertragen kann, darunter: •

Dateizugriffe

•

Benutzer-Authentisierungen

•

Domänen-Daten z.B. zwischen PDC und BDC

566

SMB/CIFS

21.8.2 SMB, NFS, CIFS In jüngerer Zeit bemüht sich Microsoft darum, SMB neben oder anstelle von NFS (Network File System) als Internetstandard durchzusetzen. SMB = Server Message Block heißt in diesem Zusammenhang dann CIFS = Common Internet File System. Welcher Erfolg diesen Bemühungen beschieden sein wird, ist noch ungewiss. Am SMB-Protokoll sind keine Konfigurationen vorgesehen. Als Schicht-7-Protokoll hat SMB mit dem Netzwerk an sich nichts mehr zu tun: Es betreibt keine MAC- oder IP-Adressierung und kein Routing.

21.8.3 Fehler im Umfeld von SMB Die Fehler, die der Autor in seiner Analysetätigkeit in den letzten Jahren beobachten konnte, waren teilweise so schwer, dass ganze Netze in den Stillstand gerieten. Allerdings ist es höchst problematisch, von SMB-Fehlern zu sprechen, da jeweils kaum der Protokolltreiber an sich fehlerhaft gewesen sein dürfte – er tat nur, wie ihm geheißen ward. Die folgenden Darstellungen sind ganz sicher nicht vollständig, und sie reißen das Theme auch nur kurz an. Die geschilderten SMB-Fehler können größtenteils von den heute gängigen Expertensystemen nicht erkannt werden; es ist immer noch die gute, alte Handarbeit, die hier zum Tragen kommt.

21.8.4 Fehler: Loops in Dateizugriffen Es wurde mehrfach selbst noch in jüngster Vergangenheit (1999) in verschiedenen Netzen unterschiedlicher Kunden beobachtet, wie zwei Formen von Zugriffsschleifen auftraten: •

Eine Datei wird geöffnet, gelesen, geschlossen – und gleich wieder geöffnet, gelesen, geschlossen – und gleich wieder .... – und gleich wieder ... – und während dessen erscheint auf dem Bildschirm des Clients – nichts. Erst viele Dutzend Zugriffe später »merkt« der Client (hier: WinNT 4.0), dass er die Daten doch schon längst hat, und bringt sie endlich auf den Bildschirm. Im vorliegenden Falle war dies ein Ingenieurbüro, das CAD-Stationen betrieb; die Dateien waren durchaus schon bis 100 Mbyte groß – und das wiederholte Laden einer Datei (bis zu 30 Mal) dauerte dann 10 oder 20 Minuten.

•

Die Ursache: Eine Datei wird geöffnet, gelesen, ... und an irgend einer Stelle innerhalb der Datei wird an eine frühere Stelle zurück gesprungen; dann also wieder: Lesen ... Rücksprung ... Lesen ... Rücksprung ...

Kapitel 21 • Windows Networking

567

Bei einem Kunden trieb das ein Client-PC den ganzen Tag über (Sommer 1999), und das LAN-Segment wurde mit über 80% Netzlast belegt – nur aus diesem Vorgang!! Anwenderkommentare: »Das Netzwerk ist heute so langsam.« Recht haben sie – und doch irren sie. Loops können für das Netz und die angeschlossenen Rechner absolut tödlich sein – sie stellen mit das schlimmste Szenario überhaupt dar; auch deswegen, weil es nur mit viel Aufwand zu diagnostizieren ist, woher der Fehler kommt. Denn in Frage kommen: •

Fehler im Treiber

•

Inkompatibilitäten verschiedener Treiber (aber jeder für sich unauffällig)

•

Applikationsfehler

21.8.5 SMB/NCP – doppelter Redirector Ebenfalls im Sommer 1999 konnte bei einem Kunden beobachtet werden, wie bei massenhaften Zugriffen einer WinNT-Maschine auf verschiedene Server jede Datei doppelt geöffnet, gelesen, geschlossen wurde. Die Zugriffe erfolgen aus derselben Anwendung, absolut synchron, und über zwei Treibersysteme: •

NetBT mit IP – TCP – SMB

•

NetWare IPX – NCP

Mit jedem der beiden Treiber war ein sog. Redirector (Rdr.sys) verbunden, der den Zugriff auf ferne Dateisysteme lenkt. Das Problem ist Microsoft im Prinzip schon länger bekannt; es ist jedoch nur schwer in den Griff zu bekommen, da hier auch die Treiber von Drittherstellern mitspielen müssen. In diesem Falle war der NetWare 32-Bit-Client von Novell beteiligt.

21.8.6 SMB Write-Befehle mit 0 Bytes Es ist immer wieder mal zu sehen (bei verschiedenen Kunden und Anwendungen), wie Applikationen scheinbar den Befehl geben, Daten auf den Server zu schreiben – mit Paketen, die 0 Byte enthalten.

568

WinNT Server hat lange Antwortzeiten

21.8.7 SMB File Handle ist falsch/0xFFFF Im Umgang mit Dateien wird nur beim Öffnen der Pfad samt Dateiname durch den Client übergeben; danach gibt der Server einen kurzen Zugriffsschlüssel zurück, den File Handle mit einer Länge von zwei Byte. Obwohl der Fehler längst laut Microsoft behoben sein soll, war er bis Ende 1999 auf WinNT 4 SP4 immer noch zu sehen. Die Auswirkungen waren bzw. sind ungewiss. Es ist möglich, dass der Fehler im Zuge der raschen Abfolge von Service Packs zum Jahr-2000-Problem nun behoben ist.

21.9

WinNT Server hat lange Antwortzeiten Wenn Anwender sagen: »Das Netzwerk ist langsam!«- dann besagt das: Es werden lange Antwortzeiten beklagt. Das liegt oft am Server, der nicht mit der Arbeit nachkommt. Dies liegt oft -auch- daran, dass die Speicherzuweisung bei WinNT-Servern nicht stimmt.

21.9.1 Speicherverwaltung bei WinNT Server Aus historischen Gründen belegt der Serverdienst nicht den tatsächlich zur Verfügung stehenden, physikalischen und/oder virtuellen Speicher. WinNT belegt für die Systemprozesse in der Regel zunächst nur 32 Mbyte des Hauptspeichers. Weite Teile des Hauptspeichers bleiben ggf. ungenutzt. Dies hängt im Einzelfall von den weiteren Diensten und Applikationen ab.

21.9.2 Memory-Tuning und Speed-Up WinNT-Spezialisten beschreiben den Geschwindigkeitssprung nach vorne, der mit Speicher-Tuning erreicht werden kann, mit 100-400%!! In Worten: bis zum Vierfachen schneller! Das wäre - salopp gesprochen - etwa so, als würden sie im Backbone von 100 Mbps auf 400 Mbps aufrüsten (oder von 1 Gbps auf 4 Gbps). Jedenfalls könnte es sein, dass die Antwortzeiten der Clients drastisch verkürzt werden: »Ist das Netzwerk aber schnell geworden« – das könnte die Reaktion sein. Der Parameter in der Registry wird vom WinNT Server-Dienst nicht von sich aus in die Registry gelegt; er muss also manuell angelegt werden. Bitte konsultieren Sie darum die einschlägigen Anweisungen von Microsoft, da manuelle Eingriffe in die Registry immer ein Risiko beinhalten. Das trifft allerdings für die von Microsoft eingetragenen – oder auch nicht eingetragenen – Registry-Parameter oft genauso zu – wo ist da dann der Unterschied?

Kapitel 21 • Windows Networking

569

WinNT Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ ..\LanmanServer\Parameters\MaxNonpagedMemoryUsage ..\LanmanServer\Parameters\MaxPagedMemoryUsage Listing 21.13: WinNT Registry-Einträge zum Memory-Tuning und Speed-Up

21.10 WinNT: Infektionen & Wilderei Es gibt eine Art von Fehlern, die zu beschreiben schon an Okkultismus grenzt. Ich kann nur guten Gewissens sagen: Ich habe alles gemessen, und alles ist bewiesen! Ansonsten diene dieser Abschnitt allen zur Warnung – und LAN-Analysten zum Beispiel, worauf am Ende doch zu achten ist!

21.10.1 PrintServer trieb WinNT in den Wahnsinn In Abschnitt 21.8.4 wurde der Fall von Zugriffsschleifen beim Laden u.a. von CAD-Dateien beschrieben. Dieser Fall führt zu einem Phänomen bei WinNT, das es immer wieder spannend macht, Netzwerkanalyse zu betreiben. Das Interessante an diesem Fall war: Alle Büros dieses Unternehmens waren bundesweit identisch ausgestattet; sämtliche WinNT-Clients kamen aus einer zentralen Werkstatt in Köln. Aber nur die Niederlassung in Hannover hatte diesen Fehler – in allen anderen Niederlassungen lief alles einwandfrei. Was war der Unterschied? Wenn ich mich richtig erinnere, stellte sich hinterher heraus, dass die Niederlassung in Hannover an den zentralen Richtlinien vorbei ein externes PrintServerModul gekauft und an die Leitung gehängt hatte – und nach Entfernung dieses Gerätes lief dann alles wieder gut. Das heißt im Ergebnis: Ein externes Ereignis auf der Leitung (denn das ist ein PrintServer) hat die WinNT Workstations dazu gebracht, in einem davon gänzlich unabhängigen Treiber-Modul völlig durchzudrehen!

21.10.2 WinNT kennt DNS-Namen und fragt sie alle ab ... Ein anderer Kunde hatte im Sommer 1999 im Zuge der Y2K-Umstellungen Probleme mit den neu eingeführten WinNT-Rechnern, u. a. mit WINS; aber auch sonst lief alles nicht so, wie es sein sollte.

570

WinNT: Infektionen & Wilderei

Abgesehen davon, dass die WINS Knoten-Typen kurios eingestellt waren, stellte sich Folgendes heraus: Es konnte exemplarisch an einem WinNT-Client nachgewiesen werden, wie er sich selber zum Absturz brachte: Erst bootete der Rechner, holte sich vom DHCP-Server die eigene IP-Adresse und die WINS-Einstellungen, prüfte über ARP-Broadcasts die eigene IP-Adresse, meldete sich beim WINS an (Registration) ... so weit, so gut. Dann aber begann dieser Rechner in Hunderten von Paketen nach WfW/Win95Workgroups zu suchen, die er niemals kennen durfte! Als das während der Vorführung via Video-Beamer gezeigt wurde, wurde Unruhe laut: Wie das sein könnte? Ich konnte die Herren beruhigen: Das war noch gar nichts! Denn danach war zu sehen, wie dieser WinNT-Client in nicht enden wollender Form scheinbar ganze DNS-Tabellen durchlief, indem ein DNS-Server um Auflösung so ziemlich jedes DNS-Namens angehalten wurde, die es dort im Netz gab – nur: Erstens: Der WinNT-Client war in einer Außenstelle, wo nie jemand mit diesen Maschinen via DNS oder sonstwie kommuniziert hätte! Zweitens: DNS war auf den WinNT-Clients (auch bei diesem) abgestellt! Dass der WinNT-Client sich - während er quasi heißlief - dann noch aufhing, konnte schon niemanden mehr wundern; so blieb der WAN-Leitung wenigstens noch der Rest erspart. Es konnte nie geklärt werden, woher der WinNT-Rechner die Kenntnis der DNSNamen und WfW/Win95-Workgroup-Namen erlangt hatte. Als Voraussetzung darf angenommen werden, dass aus der Zentrale in verbotener bzw. unerwünschter Weise Nachrichten in die Außenstelle gesendet worden waren, aus denen der/ die WinNT-Client(s) diese Daten »lernen« konnten. Fazit: WinNT-Maschinen sind sporadisch nicht mehr zu kontrollieren.

21.10.3 RUMBA-Zugriffe auf Non-Rumba-PC Ein sehr ähnliches Ereignis hatte im Sommer 1999 ein zweiter Kunde: Client-PCs (WinNT) stürzten ab, »das Netzwerk war langsam«. Auch hier konnte der sehenswerte Absturz eines WinNT-Clients beobachtet werden, der den Netzwerk-Administrator mehr als nur nervös machte: Dieser WinNT-Client drehte fast endlose Schleifen beim Zugriff auf eine Datei RUMBA.INI (SNA Terminal Emulation) – nur: Auf diesem Rechner hatte niemals jemand mit RUMBA gearbeitet, und niemals war der Rechner entsprechend konfiguriert worden – der Admin war bereit, das zu beschwören! Das überzeugendste Argument, das der Netz-Admin vortrug, war: Unter mehreren Hundert WinNT-Clients gäbe es im ganzen Unternehmen nur noch drei, höch-

Kapitel 21 • Windows Networking

571

stens fünf Anwender, die mit RUMBA arbeiteten! Und dieser Anwender sei gewiss nicht dabei – in der ganzen Außenstelle gebe es keinen einzigen Mitarbeiter bzw. Rechner, der mit RUMBA arbeiten würde! Das Rätsel konnte nicht mehr gelöst werden – es bestätigte aber die allgemeine Erfahrung: WinNT-Rechner »lernen«, was sie nichts angeht; sie »plappern« untereinander und teilen sich mal dies, mal jenes mit – und wenn man Pech hat, drehen sie durch und stürzen ab, und beim Super-GAU bringen sie das ganze Netz zum Absturz. Wie gesagt: Das grenzt ans Okkulte – aber es ist doch ganz normaler Alltag.

21.11 Windows-Tools zur Netzwerkdiagnose Für eine Auflistung der Kommandos in der Eingabeaufforderung von WinNT sei auf das Kapitel »Windows-Tools« verwiesen; hier erfolgt eine allgemeine, kurze Betrachtung vorab, um ihren diagnostischen Wert einzuschätzen. Außerdem ist bitte das Kapitel »TCP/IP Diagnose-Tools« zu beachten. Die von Microsoft mitglieferten Windows-Tools sind inzwischen teilweise zu mächtigen Diagnoseprogrammen herangewachsen – wenn sie denn nur nicht etwas behäbig in der Eingabeaufforderung bzw. DOS-Box laufen würden! Der Netzwerkmonitor von Microsoft (SMS), der sogar einen Analyzer beinhaltet, ist hier nicht aufgeführt; hier geht es um die kleinen Kommandozeilenbefehle für die DOS-Box (mit Ausnahme von Browmon.exe, das hier aus der Reihe schlägt), mit denen lokale Einstellungen und Tabelleninhalte abgefragt bzw. geändert werden können. Diese WinNT-Tools stammen teilweise historisch aus der Unix-Welt, wo sie seit langer Zeit zum Inventar gehören (wie etwa: arp, ping, traceroute). Professionelle Windows-Werkzeuge, die mit diesen Mechanismen arbeiten, können durchaus beachtliche Wirkung haben. Hierzu ist bitte im Kapitel »TCP/IP Diagnose-Tools« nachzulesen. Die hier genannten Windows-Tools haben grundsätzlich einen Nachteil, der in der Systematik der Messung sehr schwer wiegt: Man müsste sich auf die Auskunft eines Rechners verlassen, der möglicherweise nicht fehlerfrei arbeitet. Es kann nicht schaden, sich »quick-and-dirty« eine schnelle, kurze Auskunft zu holen; das kann aber nur dazu dienen, Hinweise zu erhalten; die Verifikation müsste sowieso mit dem Analyzer erfolgen. Andererseits ist es unverzichtbar, sich an diese Programme zu gewöhnen, weil sie eben immer da sind, der Analyzer aber nicht. Außerdem kann im Einzelfall der Anwender, der wegen einer Störung angerufen hat, gebeten werden, selber diese kleinen Kommandos auszuführen und das Ergebnis durchzugeben (sofern der Anwender überhaupt die Eingabeaufforderung bzw. DOS-Box aufrufen darf).

572

Windows-Tools zur Netzwerkdiagnose

Abb. 21.31: WinNT-Befehl in der DOS-Box: ipconfig /all

Abb. 21.32: Das Kommando für NetBT: nbtstat

Leider ist es diesen Tools zu eigen, in ihrer Informationsausgabe nicht immer glücklich programmiert zu sein. Dass da etwas steht (oder nicht), ist nicht immer ein Beweis für das eine oder andere (oder das Gegenteil von allem zusammen). Die IP-Konfiguration wird bei Win95/98-Rechnern mit WINIPCFG.EXE abgefragt, wie in Abbildung 21.33 zu sehen; die volle Darstellung ist zu sehen in Abbildung 21.24.

Kapitel 21 • Windows Networking

573

Abb. 21.33: Win95/98: WINIPCFG.EXE

Für die zweifelhafte Zuverlässigkeit der Angaben dieser Tools sei folgendes Beispiel angeführt: Es war oft zu beobachten, dass in WINIPCFG.EXE angezeigt wurde: »NetBIOS-Auflösung mit DNS = NEIN«, und trotzdem fand diese Auflösung statt (ein bekanntes Problem bei installiertem DFÜ-Netzwerk). Es hilft also am Ende nur der Blick in die Registry (siehe Abschnitt 21.12) oder auf die Leitung – und weniger das Abfragen mit den kleinen Windows-Kommandos. Der Autor, der fast schon nachts den Analyse-Laptop unterm Kopfkissen liegen hat :-), nutzt die kleinen Kommandozeilen-Tools von Windows wirklich nur, wenn der diagnostische Wert eindeutig ist. Es sei noch einmal auf das ausführliche Kapitel »Windows-Tools« verwiesen.

21.12 Registry-Analyse mit RegCheck Hinweis Beilage-CD-ROM: RegCheck.exe Neben der Analyse von Messdaten und neben der Abfrage mittels kleiner Windows-Kommandos muss unbedingt die Analyse der Registry betrieben werden! So, wie der LAN-Analysator die Wahrheit über die Netzwerkkommunikation ans Tageslicht bringt, kann nur durch Registry-Analyse die Wahrheit über die Maschinenkonfiguration gefunden werden. Auf der Beilage-CD-ROM zum Buch finden Sie das Programm RegCheck, das für diese Registry-Analyse entwickelt wurde.

574

Registry-Analyse mit RegCheck

Die Arbeit mit einem Programm wie RegCheck hat gegenüber dem Nachschauen in der Windows-Systemsteuerung (Netzwerk) einige erhebliche Vorteile: •

Die Registry enthält sehr viel mehr Parameter, als über die Windows-Systemsteuerung zugänglich gemacht wird.

•

Die Navigation in der Systemsteuerung ist teilweise unsystematisch.

•

Die Beschriftungen in der Systemsteuerung sind oft sehr verwirrend.

Wer einmal gelernt hat, mit der Registry umzugehen, findet sofort, was er sucht, wenn eine sortierte Darstellung gegeben ist. Die hat zwar RegEdit auch zu bieten – doch RegEdit hat gegenüber einem Programm wie RegCheck gravierende Nachteile: •

Zunächst kann ich mit RegEdit nur die Registry des lokalen Rechners auslesen.

•

Die Registry eines fremden Rechners auf dem lokalen Rechner mit RegEdit einzusehen ist ohne weiteren Aufwand nicht möglich bzw. extrem gefährlich.

Der zusätzliche Vorteil von RegCheck ist: •

RegCheck importiert die Registry in eine Datenbank.

•

Dann stehen alle üblichen Datenbank-Funktionen zur Verfügung: – Sortieren nach Hauptschlüssel, Unterschlüssel, Eintrag, Wert; – Filtern nach beliebigen Begriffen bzw. Zeichenfolgen über alle Schlüssel hinweg.

Abb. 21.34: RegEdit zum Export der Registry in eine Text-Datei (1)

Kapitel 21 • Windows Networking

575

Abb. 21.35: RegEdit zum Export der Registry in eine Text-Datei (2)

Abb. 21.36: RegEdit zum Export der Registry in eine Text-Datei (3)

•

Darstellung von Schlüsseln und Werten gleichen Themas gemäß dem tatsächlichen Interesse auch außerhalb der Registry-Struktur (geht in RegEdit definitiv nicht, da RegEdit immer die Baumstruktur beibehält).

•

Gleichwohl wird RegEdit benötigt, um für RegCheck die Registry zu exportieren. Dies geht wie folgt:

576

Registry-Analyse mit RegCheck

In Abbildung 21.34 ff. ist der Weg beschrieben, der zum Exportieren der Registry durchlaufen werden muss. Es kann frei gewählt werden, ob die gesamte Registry exportiert werden soll oder nur ein Unterschlüssel. Im Beispiel der Abbildung 21.36 werden nur die Unterschlüssel aus HKEY_LOCAL_ MACHINE\System\CurrentControlSet in die Datei WinReg_HKLM_CurrentControlSet.REG exportiert. Die für die Datenkommunikation erheblichen Einstellungen sind überwiegend in folgenden Registry-Schlüsseln enthalten: HKEY_LOCAL_MACHINE\Software\Microsoft HKEY_LOCAL_MACHINE\System\CurrentControlSet Listing 21.14: WinNT Registry-Einträge zur Datenkommunikation

Es verkürzt die Zeit des Importierens nach RegCheck und die Navigation in RegCheck, wenn die Zahl der Einträge begrenzt wird; immerhin kann eine voll ausgewachsene Registry mehrere Zehn- oder Hunderttausend Einträge enthalten. Die in eine *.REG Datei exportierten Registry-Einträge könn(t)en nun auch mit einem Textverarbeitungsprogramm gelesen werden (Abbildung 21.37; die fett gesetzten Zeilen wurden vom Autor hervorgehoben).

Abb. 21.37: Exportierte Registry-Einträge: *.REG Datei in WinWord

Kapitel 21 • Windows Networking

577

Dieses Verfahren ist dienlich, wenn man schnell-und-simpel einen oder zwei Werte auslesen will und an sonstigen Einträgen oder Zusammenhängen nicht interessiert ist. Mehr ist mit einem Textverarbeitungsprogramm eben nicht möglich.

Abb. 21.38: Filter in RegCheck auf »netbt«(NetBIOS-over-TCP/IP)

Es bietet sich darum an, die Registry-Einträge aus der *.REG Datei in eine Datenbank einzulesen. RegCheck stellt die Registry sodann in Form von Tabellen dar. Das sieht zwar etwas nüchterner aus als der Registry-Baum von RegEdit, eröffnet aber eben alle Funktionen einer Datenbank: Tabellenverknüpfung, Suchindizes, Sortierindizes, Filterfunktionen.

Abb. 21.39: Das Programm RegCheck (auf Beilage-CD-ROM) mit dem WinNTSchlüssel für die NetBIOS-Namens-Auflösung über DNS

578

Registry-Analyse mit RegCheck

Es wurde am Ende von Abschnitt 21.11 als Beispiel das Problem der NetBIOSNamensauflösung via DNS angesprochen. In RegCheck gibt es zur Verifikation zwei Möglichkeiten: Entweder scrollt man durch die Tabelle der Schlüssel, bis man bei NetBT\Parameters angelangt ist (was etwas lästig ist), oder man setzt einen Filter, der die Tabelle schlagartig auf wenige Einträge verkürzt (was deutlich angenehmer ist). Der Filter auf NetBT ist schnell gesetzt, und das Ergebnis offenbart schnell den gesuchten Eintrag samt seinem Wert (Abbildung 21.39). Um bei dem Beispiel mit der NetBIOS-Namensauflösung via DNS zu bleiben: In Abbildung 21.39 ist der eindeutige Nachweis zu sehen. Die mittels RegEdit exportierte WinNT-Registry wurde in die Datenbank des Programmes RegCheck eingelesen; dort kann wesentlich besser navigiert werden als im RegEdit. So kann ohne weiteres ein Filter gesetzt werden auf »DNS« oder »NetBT«, und alle Einträge mit diesem Inhalt werden angezeigt (was bei RegEdit immer nur schrittweise geht, da dort nur gesprungen, nicht aber gefiltert wird). In diesem Falle ist schnell zu sehen: Jawohl, der Schalter ist auf »EIN« gesetzt (0x00=AUS, 0x01=EIN). Ein Filter auf »DNS« ist im Verfahren interessanter, weil er Zusammenhänge aufweist, die bei einer Suche nur innerhalb eines Unterschlüssels (hier: NetBT\Parameters) nicht sichtbar würden; Abbildung 21.40 zeigt, dass DNS-Parameter in den verschiedensten Registry-Keys auftreten, innerhalb von HKEY_LOCAL_MACHINE\ System\CurrentControlSet sind dies etwa »Services\Tcpip\ServiceProvider« oder fürs Netzwerk-Drucken auch »Control\Print\Providers\LanMan Print Servers« (und andere mehr).

Abb. 21.40: RegCheck mit Filter auf »DNS«

In Abbildung 21.41 sind Registry-Schlüssel gefiltert, in denen die Zeichenfolge »Timeout« enthalten ist; es wird sofort sichtbar, dass verschiedene Netzwerktreiber (»Transports«) mit unterschiedlichen Timeouts arbeiten.

Kapitel 21 • Windows Networking

579

Abb. 21.41: RegCheck mit Filter auf »Timeout«

Grundsätzlich empfiehlt es sich, von allen Rechnern des Netzwerkes in regelmäßigen Abständen die Registry zu exportieren und auf einem Netzwerk-Server abzulegen, um im Falle eines Fehlers mit Programmen wie RegCheck schnellen Zugriff zu haben. Dann lassen sich Messdaten des Analyzers sowie Windows-Registry-Einträge schnell abgleichen.

Kapitel 22 Windows-Tools 22.1 22.2 22.3 22.4 22.5 22.6 22.7 22.8 22.9 22.10 22.11 22.12 22.13 22.14 22.15

arp browstat browmon finger hostname ipconfig lpq lpr net nbtstat netstat nslookup ping route tracert

582 583 584 584 585 585 586 586 587 591 592 595 596 604 605

582

arp

Dieses Kapitel bespricht die mit WinNT ausgelieferten Windows-Kommandos zur Netzwerkdiagnose; die traditionellen Unix-Kommandos zur Netzwerkdiagnose sind im Kapitel »TCP/IP Diagnose-Tools« beschrieben. Folgende Windows-Kommandos werden besprochen: Befehl

Zweck

arp

Anzeigen der Einträge der ARP-Tabelle (ARP Cache)

browmon

Browser Monitor / Windows-Programm

browstat

Browser Statistics / DOS-Box / gibt lokale und ferne Tabellen aus

finger

Abfrage von aktiven Benutzern an fernen Rechnern

hostname

Gibt den Namen des lokalen Systems aus

ipconfig

Gibt die Konfiguration des TCP/IP-Treibers aus

lpq / lpr

Abfrage von Drucker-Warteschlangen

net

Auskunft über den lokalen Rechner, Redirector etc.

nbtstat

Gibt aus bzw. überprüft: NetBIOS-over-TCP/IP Verbindungen, LMHOST-Chache, Registrierte Namen, Scope ID

netstat

Abfrage von Netzwerkverbindungen

nslookup

Abfragen des Internet DNS, etwa DNS-Namen der Win-Rechner

ping

Prüfen, ob ein IP-Rechner erreichbar ist

route

Ausgabe oder Änderung der Routing-Tabelle

tracert

TraceRoute – ausführlichere Routen-Prüfung als bei Ping

Tab. 22.1: Dienstprogramme zu TCP/IP und NetBIOS bei WinNT

Einige dieser Tools sind im Resource Kit für Windows NT zu finden.

22.1

arp Das Kommando arp bewirkt: Auszüge aus der ARP-Tabelle; Löschung von Einträgen in der ARP-Tabelle. Syntax: arp -a

[IP_Address]

[-N {MAC_Address}]

Anzeige von Einträgen der ARP-Tabelle (IP-Adressen / MAC-Adressen). Wird eine IP-Adresse angegeben, so wird die Abfrage entsprechend eingegrenzt.

Kapitel 22 • Windows-Tools

arp -d

583

IP_Address [MAC_Address]

Löscht den ARP-Eintrag der angegebenen IP-Adresse. arp -s

IP_Address MAC_Address

Legt einen neuen ARP-Eintrag an.

22.2

browstat Das Kommando browstat bewirkt: Anzeige des Hauptsuchdienstes einer WinNT-Domain oder Windows-Arbeitsgruppe (WfW, Win95/98) samt aller Sicherungssuchdienste. Weiterhin kann ein aktiver Hauptsuchdienst (Master Browser) angehalten und/oder die Wahl eines neuen erzwungen werden. Es muss jeweils zum BrowStat-Befehl der Name des Transporttreibers angegeben werden. Dieser kann in der Systemsteuerung / NetBIOS-Konfiguration ermittelt werden. Steht dort etwa »NetBT -> DKLFET«, so ist als Name des Transporttreibers »netbt_dlkfet« anzugeben. Syntax: browstat Befehl

[ {transport_driver} {domain_name} | /help]

Die verschiedenen Befehle sind: browstat elect

[transport_driver] [domain_name]

Löst in der genannten Domain die Wahl eines neuen Master Browsers aus. browstat getblist

[transport_driver] [domain_name]

Bezieht eine Liste aller Sicherungssuchdienste in der genannten Domain. browstat getmaster [transport_driver] [domain_name]

Bezieht den NetBIOS-Namen des Master Browsers der genannten Domain.

584

browmon

browstat getpdc

[transport_driver] [domain_name]

Bezieht den NetBIOS-Namen des Primary Domain Controllers (PDC) der genannten Domain. browstat listwfw

[transport_driver] [domain_name]

Bezieht eine Liste aller WfW-Rechner, die zurzeit einen Suchdienst betreiben. browstat stats

[transport_driver] [domain_name]

Gibt Statistiken des Suchdienstes aus. browstat status

[transport_driver] [domain_name]

Gibt Statusmeldungen über die angegebene Domain aus. browstat tickle

[transport_driver] [domain_name]

Erzwingt den Stop des Master Browsers in der angegebenen Domain. browstat view

[transport_driver] [domain_name|server_name]

Schickt einen NetServerEnum-Befehl zu einem Server oder einer Domain.

22.3

browmon BROWMON.EXE ist ein grafisches Windows-Programm, das in etwa die Informationen anzeigt wie browstat (siehe 22.2). Es ist kein Zeilenkommando für die Eingabeaufforderung.

22.4

finger Das Kommando finger bewirkt: Auskünfte über eingeloggte Benutzer ferner Rechner, sofern dieser den FingerDienst (finger daemon) gestartet hat.

Kapitel 22 • Windows-Tools

585

Syntax: finger -l

[Benutzer@]HostName

Zeigt im langen Listenformat die Auskünfte zu dem angegebenen Benutzer an. Wird kein einzelner Benutzer angegeben, werden alle Benutzer des genannten fernen Rechners aufgeführt. Als Host-Name kann eine IP-Adresse oder ein auflösbarer Name angegeben werden.

22.5

hostname Das Kommando hostname bewirkt: Ausgabe des aktuellen Host-Namens. Syntax: hostname

22.6

ipconfig Das Kommando ipconfig bewirkt: Die Anzeige der Einstellungen der Protokolltreiber zu TCP/IP. Wichtig ist diese Abfrage ggf. auf DHCP-Clients, da deren Einstellungen dynamisch gesetzt werden. Syntax: ipconfig

Wird das Kommando ohne Parameter gestartet, werden alle wichtigen Angaben in der Übersicht angezeigt. ipconfig /all

Gibt eine vollständige Anzeige aus; ohne /all werden nur IP-Adresse, SubnetzMaske und Default_Gateway je LAN-Adapter angezeigt. ipconfig /renew

[Adapter]

586

lpq

Erneuert die DHCP-Parameter, sofern der aktuelle Rechner als DHCP-Client konfiguriert ist. Als Adaptername muss der Name angegeben werden, der bei der Eingabe von ipconfig (ohne Parameter) ausgegeben wird. ipconfig /release

[Adapter]

Gibt das IP-Lease beim DHCP-Server frei. Diese Funktion setzt voraus, dass der aktuelle Rechner als DHCP-Client konfiguriert ist und seine Einstellungen vom DHCP-Server bezogen hat.

22.7

lpq Das Kommando lpq bewirkt: Statusabfrage einer fernen Druck-Warteschlange, die auf einem LPD-Server liegt (Line Printing Daemon). Diese Funktion setzt voraus, dass in der WindowsSystemsteuerung der Microsoft TCP/IP Druckdienst installiert wurde. Syntax: lpq -Sserver

-Pprinter

[-l]

Der Parameter -S gibt den Namen des fernen Rechners an, auf dem die mit -P angegebene Warteschlange liegt. Mit -l kann eine lange Listenausgabe erzeugt werden.

22.8

lpr Das Kommando lpr bewirkt: Versendung eines Druckauftrages in eine ferne Druck-Warteschlange, die auf einem LPD-Server liegt (Line Printing Daemon). Diese Funktion setzt voraus, dass in der Windows-Systemsteuerung der Microsoft TCP/IP Druckdienst installiert wurde. Syntax: lpr -Sserver -Pprinter [-o] [-C] [-J] [-x] [-d] DateiName

Die mit Dateiname angegebene Datei wird an den mit -S benannten fernen Rechner gesendet, auf dem die mit -P angegebene Warteschlange liegt. Mit -o wird der Dateityp angezeigt, mit -CClass wird der Inhalt der Vorsprannseite für die Drukkerklasse angegeben, mit -JJob wird der Name für den Druckjob angegeben; mit -x wird die Kompatibilität mit SunOS, Version 4.1.x und früher, angezeigt; mit -d wird zuerst die Datei gesendet (vor den Steuerdaten).

Kapitel 22 • Windows-Tools

22.9

587

net Das Kommando net bewirkt: Ausgabe von Konfigurationsdaten zum Netzwerk bzgl. des lokalen Rechners. Syntax: net config

Zeigt die aktuellen Einstellungen der Arbeitsgruppe. net diag

Startet das Netzwerkdiagnose-Programm von Microsoft; dieses muss auf einem anderen Netzwerkrechner verfügbar sein. net diag /status

Zeigt Diagnosestatistiken zum NetBIOS-Protokoll des lokalen Rechners oder eines fernen NetBIOS-Rechners an. net time

Sucht einen Zeit-Server um die lokale Zeit zu synchronisieren. net ver

Zeigt die Version des aktuellen Redirectors an (Rdr.sys). net view

Zeigt Netzwerkrechner der aktuellen Domain oder Arbeitsgruppe samt der Freigaben bzw. Ressourcen an. Beispiele: Die folgenden Abfragen mit net diag /status (Abbildung 22.1 ff.) beziehen sich zunächst auf den lokalen Rechner (Win95), dann auf einen ersten fernen Rechner (Win95), zuletzt auf einen zweiten fernen Rechner (Win98).

588

net

Abb. 22.1: Kommando »net diag /status« – lokaler Rechner

Abb. 22.2: Kommando »net diag /status« – ferner Rechner LAPTOP_FF

Kapitel 22 • Windows-Tools

589

Abb. 22.3: Kommando »net diag /status« – ferner Rechner LAPTOP_F2

Neben den MAC-Adressen zum jeweiligen NetBIOS-Namen (dessen Eingabe in den ScreenShots nicht mehr sichtbar ist) zeigt der Befehl net diag /status den Namen der Arbeitsgruppe oder Domain an; außerdem wird durch die Angabe »__ MSBROWSE__« sichtbar, welche Maschine als Master Browser arbeitet. Im gegebenen Beipiel ist der Rechner TOWERHOME der Master Browser der Arbeitsgruppe WIN95 und der Rechner LAPTOP_F2 ist Master Browser der Arbeitsgruppe WIN98. In Abbildung 22.4 ist das Kommando net diag ohne weiteren Zusatz zu sehen. Wichtige Angaben zum Windows Troubleshooting werden hier auf einen Blick sichtbar; in der Systemsteuerung müssten unterschiedliche Fenster aufgerufen werden, um diese Angaben zu erhalten. Bei sehr schweren Windows-Fehlern ist die Versionsnummer des Redirectors wichtig. Der Redirector besorgt die Umleitung von Schreib-/Lesezugriffen auf Dateien, die im Netzwerk liegen. Der Befehl net view zeigt zunächst einmal die im Netzwerk erreichbaren Ressourcen (je Domain oder Arbeitsgruppe); das wird auch im Windows Explorer bzw. in der Netzwerkumgebung angezeigt. Zusätzlich aber zeigt er auf einen Blick in der Liste an, wofür im Windows Explorer bzw. in der Netzwerkumgebung erst einzeln je Ressource die rechte Maustaste gedrückt und die Eigenschaften abgefragt werden müssen: Maschinenname, Kommentar und Arbeitsgruppe bzw. Domain.

590

net

Abb. 22.4: Kommando »net diag« gibt lokale Konfig-Daten aus

Abb. 22.5: Kommando »net view« zu den Workgroups WIN95 und WIN98

Kapitel 22 • Windows-Tools

591

Eine Ausgabe von net view in eine Datei kann hilfreich sein, um eine schnelle Dokumentation der Netzwerkrechner in die Hand zu bekommen.

22.10 nbtstat Das Kommando nbtstat bewirkt: Ausgabe von Protokollstatistiken der NetBT-Treiber (NetBIOS-over-TCP/IP). Syntax: nbtstat -a HostName -A IP_Adr. [-c][-n][-R][-r][-S][-s][Intv.]

Es werden NetBT-Angaben zu dem mit -a Hostname oder -A IP_Address angegebenen fernen Rechner abgefragt, wobei -c den NetBIOS Name Cache auslist, -n die lokalen NetBIOS-Namen auflistet, -R die Datei LMHOSTS neu einliest (Reload), -r Statistik zur Namensauswertung ausgibt (Name Resolution), -S Server-Sitzungen der Arbeitsstationen anzeigt (Ausgabe: nur IP-Adressen), -s wie -S arbeitet, aber neben den IP-Adressen auch die NetBIOS-Namen ausgibt.

Abb. 22.6: Kommando »nbtstat -A 194.175.68.20«

592

netstat

Zuletzt noch kann ein Intervall festgelegt werden, mit dem die Abfrage laufend wiederholt werden soll; dieser Vorgang wird durch CTRL-C beendet. Hinsichtlich der Bedeutung von »__MSBROWSE__« und den Ressourcen-Typen (0x00, 0x03, 0x20 etc.) sei auf das Kapitel »Windows Networking« verwiesen.

22.11 netstat Das Kommando netstat bewirkt: Anzeige von Protokoll- und Verbindungsstatistiken zu Ethernet, IP, UPD, TCP. Syntax: netstat [-a][-e][-n][-s][-p Protocol][-r][Intv.]

Mit -a werden alle Verbindungen und UDP/TCP-Sockets angezeigt; mit -e werden Ethernet-Statistiken ausgeben; mit -n werden die Verbindungen in numerischer Form angezeigt; mit -s werden die Statistiken zu allen Protokollen angezeigt, sofern nicht mit -p auf das genannte Protokoll eingeschränkt wird (ip, icmp, udp, tcp); mit -r wird die Routing-Tabelle ausgegeben. Zuletzt noch kann ein Intervall festgelegt werden, mit dem die Abfrage laufend wiederholt werden soll; dieser Vorgang wird durch CTRL-C beendet. Beispiele: netstat netstat netstat netstat netstat netstat

-s -s -s -s -r -e

-p -p -p -p

ip icmp tcp udp

Listing 22.1: Beispiele für den Befehl »netstat«

Kapitel 22 • Windows-Tools

Abb. 22.7: Kommando »netstat -s -p ip«

Abb. 22.8: Kommando »netstat -s -p icmp«

593

594

netstat

Abb. 22.9: Kommando »netstat -s -p tcp« bei laufender FTP-Übertragung

Abb. 22.10: Kommando »netstat -s -p udp«

Kapitel 22 • Windows-Tools

Abb. 22.11: Kommando »netstat -r« / Ausgabe der Routing-Tabelle

Abb. 22.12: Kommando »netstat -e« / Ausgabe der Ethernet-Statistik

22.12 nslookup Das Kommando nslookup bewirkt: Anzeige von Daten des DNS Namens-Servers (Name Server LookUp). Syntax: nslookup [-Options...] [HostName | – {Server}]

595

596

ping

Der Zugriff auf den mit HostName angegebenen DNS-Server erfolgt mit einem in der Syntax als Option gekennzeichneten Befehl: Die Liste der verfügbaren Kommandos (Optionen) ist sehr umfangreich und soll darum hier nicht einzeln aufgeführt werden. Im Ergebnis dient das Kommando dem Auslesen von DNSTabellen und Konfigurationen bzw. der Erkennung von Fehlern im DNS-System.

22.13 ping Das Kommando ping bewirkt: Test von IP-Verbindungen durchs Netzwerk zu anderen IP-Teilnehmern unter Einstellung aller möglichen IP-Parameter und Zeitwerte. Syntax: ping [-t] [-a] [-n Anzahl] [-l Länge] [-f] [-i TTL] [-v ToS] [r Anzahl] [-s Anzahl] [{-j HostList}|{-k HostList}] [-w Timeout] IP_ Address/HostName

Neben der einfachsten Befehlsform wie ping 194.38.5.29, bei der mit Standardeinstellungen gearbeitet wird, bietet der Ping-Befehl die Möglichkeit, alle Parameter des IP-Protokolls auszunutzen, um Fehler in der Übertragung der IP-Pakete im Netzwerk ausfindig zu machen. Beispiele:

22.13.1 ping -a ~ Namensauflösung ping -a IP_Address

Bei -a wird in der Befehlsausgabe die Statuszeile statt der IP-Adresse den entsprechenden Computer-Namen anzeigen (address resolution).

22.13.2 ping -t ~ Endloslauf ping -t IP_Address/HostName

Mit -t wird angezeigt, dass der Ping zeitlich unbegrenzt weiterlaufen soll, bis er mit CTRL-C abgebrochen wird (termination).

Kapitel 22 • Windows-Tools

597

22.13.3 ping -n ~ Begrenzte Anzahl ping -n 100 IP_Address/HostName

Mit -n wird angegeben, wie viele Ping-Versuche unternommen werden sollen; hier im Beispiel sind es Hundert (number of pings). Diese Variante ist wichtig, wenn über WAN-Leitungen gearbeitet wird; hier ist die Standardanzahl von fünf Versuchen ggf. zu gering.

22.13.4 ping -l ~ Einstellung der Paketlänge ping -l PacketLength IP_Address/HostName

Mit -l wird die Länge des IP/ICMP-Paketes bestimmt; dies wird durch eine Auffüllung des Paketes mit Testdaten erreicht (packet length). Übersteigt die Datenmenge die vom MAC-Layer (Ethernet, Token-Ring) unterstützte Frame Size, wird sie über mehrere IP-Pakete verteilt, wobei nur das jeweils erste IP-Paket den ICMP-Header beinhaltet. Diese Option ist extrem wichtig für die Analyse, weil sie bei folgenden Fehlern auf die Spur hilft: •

Es wird erkannt, ob die Gegenstelle die Verteilung von ICMP-Daten auf mehrere IP-Pakete unterstützt.

•

Es wird erkannt, ob sich die Erfolge bzw. Misserfolge bei den Ping-Versuchen unterscheiden je nach Paketgröße. Dies zielt wesentlich auf Fehler bei der IP Fragmentation durch Router ab, wenn Transitstrecken, etwa mit X.25, die Größe der IP-Pakete nicht unterstützen und die IP-Pakete darum jeweils in mehrere Teilfragmente aufgeteilt werden müssen. Oft kann erkannt werden, dass Pings mit 64 Byte Standardgröße einwandfrei beantwortet werden, während Pings etwa mit 512, 1.024 oder 1.500 Bytes nicht mehr oder nur teilweise beantwortet werden.

Werden bei bestimmten höheren Paketgrößen gar keine Antworten mehr empfangen, während bei kleinen Paketen sehr wohl Antworten kommen, wird entweder •

die IP Fragmentation auf einem Router nicht unterstützt, oder

•

die Ping-Station setzt das IP Don’t Fragment Flag (DF).

598

ping

Normalerweise darf das DF-Flag nur bei dem Parameter -f gesetzt werden. Bei Verdacht, dass der IP-Treiber trotz fehlenden Parameters -f das DF-Flag setzt, muss auf der Leitung mit dem Analyzer der Fall geklärt werden. •

Werden bei bestimmten höheren Paketgrößen nur teilweise Antworten erhalten, dürfte der Router, der am Ende der Fragmentierungsstrecke arbeitet, regelmäßig nicht alle Fragmente erhalten, was zu einem Verlust des ursprünglichen Pakets führt, weil es nicht mehr zusammengesetzt werden kann. In diesem Falle müsste der Router die Rückmeldung schicken: »ICMP: Time Exceeded / Reassembly Timer Expired«. Entsprechend wäre mit dem Kommando netstat -s -p icmp nachzusehen, ob solche Meldungen eingetroffen sind. Leider zeigt netstat nur allgemein »Time Exceeded« an, ohne dabei zwischen TTL=Null und Fragmentierungsfehlern zu unterscheiden. Im Zweifel sind also die Tests mit dem Analyzer auf der Leitung zu verfolgen.

Der Test mit ping -l gehört also neben ping -f bei Verdacht auf Netzwerk- bzw. Routing-Fehler mit zu den wichtigsten Diagnosen überhaupt. Zu den ggf. erforderlichen Registry-Anpassungen siehe weiter unten: Listing 22.2.

22.13.5 ping -f ~ Fragmentierungstest ping -f IP_Address/HostName

Mit -f wird Ping angewiesen, in den IP-Paketen das Steuer-Bit Don’t Fragment (DF) zu setzen (don’t fragment). Das hat folgende Wirkung(en): Sollte sich das IP-Paket bei einem Router als zu groß für die physikalische Rahmengröße der Ausgangsleitung erweisen, und sollte der Router das IP-Paket darum in mehrere Teilfragmente zerlegen wollen, so ist dem Router dieses nun nicht mehr gestattet. Die Möglichkeiten, die sich aus dem Test ergeben, sind: •

Wenn bei Pings ohne den Schalter -f Antworten der Gegenstelle zurückkommen, bei gesetztem Schalter -f aber nicht (also bei DF-Bits im IP-Header), so befindet sich auf dem IP-Vermittlungsweg zur Gegenstelle eine Transitstrecke, die mit kleineren Paketgrößen arbeitet, als der dortige Router mit den PingPaketen zugesendet bekommt. Der Router müsste fragmentieren, darf aber wegen des DF-Bits nicht, und hat auch keine zweite Vermittlungsstrecke zur Verfügung. Er verwirft das Paket und sendet die Meldung zurück: »ICMP: Fragmentation Needed.«

Kapitel 22 • Windows-Tools

•

599

Auf alle Pings gibt es Pongs zur Antwort, ungeachtet des Schalters -f. Die je nach DF-Bit verschiedenen Versuche unterscheiden sich jedoch erheblich in der Antwortzeit zwischen Ping und Pong. In diesem Fall hat ein Router sehr wahrscheinlich einen Weg, auf dem nicht fragmentiert werden muss, sowie einen zweiten, bei dem die IP-Pakete zerlegt werden müssen. Entsprechend unterscheiden sich die Laufzeiten.

•

Wenn zwischen Pings mit und ohne Schalter -f kein Unterschied besteht, hat ein ggf. vorhandener Fehler sehr wahrscheinlich mit der IP Fragmentation im IP-Vermittlungsweg nichts zu tun.

Gemeinsam mit ping -l ist dies die wichtigste Ping-Variante. Der Versuch sollte mit dem Analyzer aufgezeichnet werden, um ggf. eintreffende ICMP-Meldungen von Routern auslesen zu können. Gegebenenfalls ist in der Registry die eine oder andere Einstellung anzupassen, um Fehler in der IP Fragmentation zu vermeiden. 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 Listing 22.2: WinNT Registry-Einträge zur MTU (Maximum Transmission Unit)

22.13.6 ping -t ~ Hop Credit: TTL ping -t 128_IP_Address/HostName

Mit -t wird Ping angewiesen, die IP-Pakete mit einem bestimmten TTL-Wert auszustatten (time-to-live). Der TTL-Wert beeinflusst, wie weit das IP-Paket auf seinem Vermittlungsweg kommt (darum auch Hop Credit = Guthaben genannt), da jeder Router den TTLWert im IP-Header um mindestens »1« (oder mehr) vermindert. Bei dem Router, der den Wert schließlich auf Null herabzählt, wird das IP-Paket verworfen; dieses Ereignis wird vom Router mit der Rückmeldung »IMCP: Time Exceeded / TTL Expired« quittiert.

600

ping

Entsprechend wäre mit dem Kommando netstat -s -p icmp nachzusehen, ob solche Meldungen eingetroffen sind. Leider zeigt netstat nur allgemein »Time Exceeded« an, ohne dabei zwischen TTL=Null und Fragmentierungsfehlern zu unterscheiden. Mit ping -t kann bei wechselnden TTL-Werten in etwa der Test nachgestellt werden, der durch das Kommando tracert (traceroute) automatisch durchgeführt wird: •

Kommen bei allen TTL-Werten Antworten zurück, spielt der TTL-Wert keine Rolle, weil der Empfänger im selben IP-Subnetz liegt, was auch einen Empfang bei TTL=Null erlaubt.

•

Kommen nur bei großen TTL-Werten Antworten zurück, bei kleinen TTLWerten aber nicht, ist der IP-Vermittlungsweg mit großen Wegekosten (costs) verbunden. Als Cost wird die Summe aller TTL-Werte bezeichnet, die von allen Routern auf dem Vermittlungsweg abgezogen werden; die abstrakte Rechnung mit Cost ist wichtig, da einzelne Router den TTL-Wert um mehr als nur »1« vermindern können; in diesem Falle entspräche der zur Vermittlung erforderliche TTL-Wert nicht zugleich der tatsächlichen Anzahl der Router (sondern den aufsummierten Cost-Werten).

Mit etwas Geduld und wechselnden TTL-Werten im Kommando ping -t findet man den exakten Cost-Wert für einen gegebenen IP-Vermittlungsweg heraus. Sollten regelmäßig IP-Teilnehmer über Fehler in IP-Sessions klagen, könnte in der WinNT-Registry der entsprechende Parameter für den Vorgabewert von TTL angepasst werden. Allerdings hilft diese Einstellung nicht, wenn die jeweilige Applikation den fehlerhaften (= zu geringen) TTL-Wert selbst erzwingt. WinNT Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\ Options\37 (= Default TTL Option) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters\DefaultTTL Listing 22.3: WinNT Registry-Einträge zu IP TTL (Time-To-Live)

22.13.7 ping -v ~ IP Type of Service (ToS) ping -v ToS-Wert_IP_Address/HostName

Mit -v wird ein bestimmter IP Type of Serve (ToS) bewirkt (ToS value).

Kapitel 22 • Windows-Tools

601

Dies könnte folgende Wirkung(en) haben: •

Während Pings ohne ToS beantwortet werden, sind bei ToS-Pings keine Antworten zu empfangen. Dann gibt es Router, die IP-ToS nicht unterstützen und die Pakete verwerfen.

•

Auf Pings mit bestimmten ToS-Werten kommen die Antworten der Gegenstelle schneller zurück als bei anderen ToS-Werten. Dies spräche dafür, dass es Router gibt, die IP-ToS unterstützen und ggf. in der Vermittlung bevorzugt behandeln. In diesem Falle könnte grundsätzlich mit veränderten ToS-Werten die Antwortzeit in IP-Sessions verkürzt werden – allerdings eindeutig zu Lasten anderer IP-Teilnehmer, die ohne diese ToS-Bevorzugung über dieselben Router arbeiten.

Es könnte sich also anbieten, den Vorgabewert für IP-ToS in der Registry anzupassen. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters\DefaultTOS Listing 22.4: WinNT Registry-Eintrag zum IP ToS (Type of Service)

Allerdings ist es unüblich, mit ToS zu arbeiten; es dürfte selten sein, dass hier Effekte verzeichnet werden.

22.13.8 ping -s ~ IP Option: Time Stamp ping -s Anzahl_IP_Address/HostName

Mit -s wird die IP-Option Time Stamp eingeschaltet; hierdurch wird der Empfänger angehalten, in dem als Antwort gesendeten IP-Paket Zeitstempel einzutragen (internet time stamp). Der Wert für Anzahl kann zwischen 1 und 4 liegen; dies beeinflusst die Länge des sog. Optionsfeldes im IP-Header. Für die Diagnose von Netzwerkfehlern ist diese Funktion in aller Regeln ohne Bedeutung. Bei exakter Parametrisierung könnte die Laufzeit zwischen verschiedenen Netzwerkabschnitten ermittelt werden; dies aber würde zwingend voraus setzen, dass alle Netzwerkkomponenten exakt auf dieselbe Zeit eingestellt wären. Das ist zwar über Zeitprotokolle machbar, aber eher selten.

602

ping

22.13.9 ping -r ~ IP Option: Record Route ping -r Anzahl_IP_Address/HostName

Mit -r wird die IP-Option Record Route eingeschaltet; hierdurch werden die Router angehalten, ihre IP-Adresse im IP-Header einzutragen (record route). Der Wert für Anzahl kann zwischen 1 und 9 liegen. Damit ist die Menge der aufgezeichneten Vermittlungsabschnitte angegeben. Der Mechanismus von Record Route wird heute bei Ping als weitgehend überflüssig erachtet, seitdem TraceRoute-Programme unter Windows ebenfalls den Verkehrsweg ausfindig machen und neben den IP-Adressen sogar die DNSNamen der Router ausgeben.

22.13.10 ping -j ~ IP Option: Loose Source Route ping -j HostList_IP_Address/HostName

Mit -j wird veranlasst, dass die in HostList (einer Datei) angegebenen Router durchlaufen werden; das entspricht einer Wegevorschrift durch den Absender. Gegenüber dem Verfahren von Strict Source Route ist in diesem Fall gestattet, dass das IP-Paket zwischen den verschiedenen genannten Routern noch andere Router überquert. Der Weg ist also nur teilweise vorgeschrieben. Für die Diagnose von Netzwerkfehlern ist diese Funktion in aller Regel nur dann von Belang, •

wenn auch die Applikationen über Loose Source Route arbeiten und

•

wenn es den Verdacht auf Fehler bei diesem Verfahren gibt.

Die Tests mit ping -j sollten mit dem Analyzer aufgezeichnet werden. Grund: Sollte ein Router die Wegevorschrift nicht einhalten können, verwirft er das IPPaket und sendet eine Rückmeldung an den Urheber: »ICMP: Destination Unreachable / Source Route Not Available«. Eine genaue Aufschlüsselung des Geschehens ist nur mit der Bildschirmausgabe von Ping nicht mehr möglich.

22.13.11 ping -k ~ IP Option: Strict Source Route ping -k HostList_IP_Address/HostName

Kapitel 22 • Windows-Tools

603

Mit -k wird veranlasst, dass die in HostList (einer Datei) angegebenen Router durchlaufen werden; das entspricht einer Wegevorschrift durch den Absender. Gegenüber dem Verfahren von Loose Source Route ist in diesem Fall keine Erweiterung des Vermittlungsweges um weitere Router gestattet. Der Weg ist also eindeutig vorgeschrieben. Für die Diagnose von Netzwerkfehlern ist diese Funktion in aller Regel nur dann von Belang, •

wenn auch die Applikationen über Strict Source Route arbeiten und

•

wenn es den Verdacht auf Fehler bei diesem Verfahren gibt.

Die Tests mit ping -k sollten mit dem Analyzer aufgezeichnet werden. Grund: Sollte ein Router die Wegevorschrift nicht einhalten können, verwirft er das IPPaket und sendet eine Rückmeldung an den Urheber: »ICMP: Destination Unreachable / Source Route Not Available«. Eine genaue Aufschlüsselung des Geschehens ist nur mit der Bildschirmausgabe von Ping nicht mehr möglich.

22.13.12 ping -w ~ Wartezeit bis zum Pong ping -w Zeitwert_IP_Address/HostName

Mit -w wird dem Ping ein Timeout-Wert mitgeteilt: Die Antwort hat bis zu dem mit -w angegebenen Zeitpunkt (gemessen ab Sendung des Pings) einzutreffen, ansonsten wird der Pong als verloren gewertet (wait timout). Der Zeitwert wird in Millisekunden angegeben. Diese Ping-Funktion dient dazu, die Antwortzeit zwischen Ping und Pong genau einzugrenzen. Dies aber ist über einen normalen Ping ohne Parameter sehr viel leichter zu erreichen, weil sowieso die Antwortzeit gemessen und ausgegeben wird.

22.13.13 Ping mit Zielliste ping Ziel-Liste

Es kann eine Datei angegeben werden, die eine Liste von IP-Teilnehmern enthält, die per Ping angetestet werden sollen.

604

route

22.13.14 ping mit kombinierten Parametern Es ist wichtig, den Wert kombinierter und wechselnder Ping-Parameter zu erkennen. Je nach Problem muss man sich auf den aktuellen Fall mit den Parametern einstellen.

Abb. 22.13: Kommando »ping -l -n« mit verschiedenen Längenwerten

In Abbildung 22.13 ist zu erkennen, wie die Antwortzeit von Test zu Test ansteigt: •

Bei 64 Byte Datenmenge beträgt sie 1 ms.

•

Bei 1.500 Byte Datenmenge beträgt sie schon 4 ms.

•

Bei 4.500 Byte Datenmenge beträgt sie gar 9-10 ms.

Es zeigt sich also, dass Laufzeitmessungen mit verschiedenen Zusatzparametern durchgeführt werden müssen. Auch der Zusatzparameter Don’t Fragment (DF) kann die Laufzeiten verändern – je nach der Übermittlungsstrecke, die ein Router dann zu wählen hat.

22.14 route Das Kommando route bewirkt: Abfragen oder Verändern der Routing-Tabelle.

Kapitel 22 • Windows-Tools

605

Syntax: route [-f] [-p] [Befehl {Ziel}{SubnetMask}{Gateway}{Metric}]

Ohne weitere Eingabe gibt route die Routing-Tabelle auf den Bildschirm. Mit -f werden die Gateway-Einträge gelöscht (free). Es gibt zusätzliche Befehle, die sämtliche statische Routen betreffen: Mit route print wird eine Route angezeigt; mit route add wird eine statische Route erzeugt; mit route delete wird eine Route gelöscht; mit route change wird eine bestehende Route geändert. Statische Routen, die mit route add angelegt werden, gelten nur bis zum nächsten Abschalten des Computers; nach dem nächsten Neustart ist sie verloren. Wird der Befehl route add dagegen erweitert als route add -p verwendet, wird die neue statische Route als Persistent Route dauerhaft gespeichert und steht auch nach dem Neustart zur Verfügung. WinNT Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters\PersistentRoutes Listing 22.5: WinNT Registry-Eintrag für dauerhafte statische Routen

Weiterhin können dem Kommando route eine Subnet-Mask übergeben werden, ein bestimmtes Gateway (Router) sowie ein Metric-Wert. Der Metric-Wert bezieht sich auf die maximale Differenz des TTL-Wertes im IPPaket zwischen Absendung und Eintreffen bei der Gegenstelle – der Differenzwert geht durch Abzüge seitens der Router verloren. Mit dem Mittel der statischen Routen können also Mindest-TTL-Werte erzwungen werden. Wird dies nicht getan, wird nur der Vorgabewert von TTL beim Starten von WinNT berücksichtigt. Siehe hierzu: Listing 22.3: WinNT Registry-Einträge zu IP TTL (Time-To-Live).

22.15 tracert Das Kommando tracert (TraceRoute) bewirkt: Austesten des IP-Vermittlungsweges und Ermittlung des erforderlichen TTLWertes.

606

tracert

Syntax: tracert [-d][-h TTL][-j HostList][-w Wartezeit]IP_Addr/HostName

Mit -d wird angezeigt, dass keine DNS-Auflösung der IP-Adressen stattfinden soll; -h gibt den Höchstwert der TTL-Werte an, mit denen die IP-Pakete auf die Reise gehen; mit -j wird eine Datei angegeben, die eine Liste der zu überquerenden Router enthält (Loose Source Route); mit -w wird die höchste Wartezeit für die Pong-Antworten angegeben. Der TraceRoute-Befehl führt einen aufwendigeren, intelligenteren Ping-Befehl durch. Beginnend mit TTL=1 wird von Versuch zu Versuch der TTL-Wert so lange erhöht, bis endlich die Pong-Antwort auf das eigene Ping eintrifft. Da jeder Router, bei dem ein Ping-Paket wegen eines auf Null gefallenen TTLWertes verworfen wird, eine Rückmeldung schickt (»ICMP: Time Exceeded / TTL Expired«), können aus diesen ICMP-Meldungen die IP-Adressen der Router ermittelt werden; und diese IP-Adressen können wiederum in DNS-Namen aufgelöst werden. Da der ganze Vorgang wesentlich darauf basiert, ICMP-Rückgaben der Router zu provozieren, sollte der Test mit dem Analyzer aufgezeichnet werden, weil der Befehl netstat -s -p icmp (siehe 22.11) zwar die Zahl der »Time Exceeded«-Eingänge auflistet, aber nicht zwischen den Ereignissen »TTL=Null« und »Fragmentierungsfehler« unterscheidet.

Abb. 22.14: Kommando »tracert -d -w 10 204.146.80.99«

Kapitel 22 • Windows-Tools

607

TraceRoute ist neben ping ein Rückgrat der IP-Analyse. Allerdings bietet das tracert von Windows nicht die vielen Möglichkeiten von ping, auf die Protokollparameter von IP zuzugreifen; so können Fehler in der IP Fragmentation mit TraceRoute nicht (oder nur indirekt) erkannt werden.

Kapitel 23 Ausblick: Windows 2000 23.1 23.2 23.3 23.4 23.5 23.6 23.7 23.8 23.9 23.10 23.11 23.12 23.13 23.14 23.15

Domains, Domain Tree, Active Directory WINS wird ersetzt durch DDNS Lightweight Directory Access Protocol Virtuelle Unternehmensnetze via Internet Verschlüsselung (A): Kerberos Verschlüsselung (B): EFS PDC und BDC werden abgelöst Replikationen / Partitionen Vertrauensstellungen Mobile Computing / Follow Me IntelliMirror Migration und Integration Mixed Mode Ausblick Messtechnik und Windows 2000

610 611 611 612 612 612 612 613 613 614 614 614 615 615 616

610

Domains, Domain Tree, Active Directory

Dieses Buch konnte Windows 2000 noch nicht berücksichtigen. Dies hat Gründe: •

Die schlussendliche Version war bei Redaktionsschluss des Buches noch nicht offiziell freigegeben.

•

Bis kurz vor Schluss hat Microsoft noch gewichtige Änderungen vorgenommen, vor allem bei dem so wichtigen Bereich der Abwärts-Kompatibilität von Windows 2000 zu NT4 auf Basis der verwendeten LAN-Protokolle.

•

Eine Beschreibung der Windows-2000-Technik hätte darum in die Irre gehen können.

Gleichwohl sollen ein paar Stichworte als Ausblick genannt werden. Ansonsten sei auf die nächste Auflage dieses Buches verwiesen. Erfahrungsgemäß kann nach sechs bis zwölf Monaten mit ersten fundierten Erfahrungen gerechnet werden. Wir werden alles tun, um Sie dann erneut mit dem nötigen Wissen auszustatten.

23.1

Domains, Domain Tree, Active Directory Windows-Domänen werden demnächst in einem Domänen-Baum organisiert. Die Technik dieser Organisation bzw. das im Hintergrund wirkende System nennt sich »Active Directory«. Die verschiedenen Teile des Active Directory sind hierarchisch strukturiert und werden entsprechend administriert. Der Zwang, dass WinAdmins sich bei jeder Domäne neu anmelden müssen, um sie administrieren zu können, entfällt. Der WinAdmin kann von einem Rechner aus alle Teile des Domänen-Baums im Active Directory verwalten. Das Active Directory beruht stark auf der Übernahme bekannter Techniken aus dem Internet wie DHCP und DNS (siehe 23.2). Das Auffinden von Ressourcen wird durch eine einheitliche Struktur wesentlich erleichert, während die frühere Struktur selbstständiger Domänen mit ihren eher eigenwilligen Vertrauensstellungen teilweise zu erheblichen Schwierigkeiten bei der Auffindung von Ressourcen bzw. beim Zugriff auf dieselben führte. Mehrere Domänen-Bäume können in einzelnen Bereichen zu »Wäldern« zusammengefasst werden. Dies erinnert wieder an die alten Vertrauensstellungen, hat aber den Unterschied, dass es keinen Zwang hierzu gibt – es können durchaus alle Domänen und Ressourcen innerhalb nur eines einzigen Domänen-Baums verwaltet werden. Die Aufteilung in verschiedene Domänen-Bäume innerhalb eines Domänen-Waldes spiegelt beispielsweise verschiedene Einzelunternehmungen innerhalb eines Konzernverbundes wider. Das bedeutet, dass bestehende Domänen-Bäume schnell in übergreifende Windows-2000-Strukturen eingebunden werden können.

Kapitel 23 • Ausblick: Windows 2000

23.2

611

WINS wird ersetzt durch DDNS Unter NT4 wurde vorrangig das alte NetBIOS over TCP/IP (»NetBT«) eingesetzt. Daraus folgte der Zwang, zwischen NetBIOS-Namen und IP-Adressen zu vermitteln: Wer von einem anderen Windows-NT-Rechner nur den NetBIOS-Namen kannte, musste irgendwoher die IP-Adresse bekommen – und umgekehrt. Im schlechtesten Falle erfolgte das mithilfe von Broadcasts, im besten Falle über die zentrale Einrichtung eines Namens-Servers: WINS (Windows Internet Name Service). WINS wird bei Windows 2000 ersetzt durch eine neue Form von DNS: DDNS = Dynamic Domain Name Service. Das bereits aus dem Internet bekannte DNS-Verfahren wurde ergänzt. Fragt ein startender Windows-Rechner bei (s)einem DHCP-Server nach (s)einer IPAdresse, und gibt der DHCP-Server die gewünschten IP-Konfigurationsdaten an den Windows-Client zurück, so übergibt der DHCP-Server diese Daten an den DNS-Server, der sie in seinen Tabellen einträgt. Sodann kann die Auflösung zwischen Maschinenname und IP-Adresse via DNS erfolgen. War der Maschinenname zuvor ein waschechter NetBIOS-Name, so ist dies jetzt ein waschechter DNS-Name. Hier hat also ein vollständiger Systemwechsel stattgefunden. Während noch bei NT4 der Windows-Client selber seine Anmeldung (»Registration«) beim WINS-Server besorgen musste, nachdem er seine IP-Daten vom DHCP-Server bezogen hatte, so erledigt dies nun der DHCP-Server für ihn. Während beim »alten« DNS die Tabellen (DNS-Name zu IP-Adresse) noch manuell gepflegt wurden, können die Einträge nunmehr automatisch durch Nachricht seitens des DHCP-Servers bzw. dynamisch erfolgen. Die Unix-Welt hat mit ihrem BIND-Verfahren diese Technik des dynamischen DNS ebenfalls implementiert; es könn(t)en also (theoretisch) auch vorhandene Unix-Rechner, insbesondere LINUX-Server verwendet werden. Hier aber sind noch reichlich Fragezeichen vorhanden.

23.3

Lightweight Directory Access Protocol Das Active Directory von Windows 2000 arbeitet zum Austausch der Systemdaten mit dem »Lightweight Directory Access Protocol« (LDAP). Jede Netzwerkkomponente, die LDAP unterstützt, kann von Windows-2000Rechnern »gesehen« und somit in das Active Directory eingebunden werden. Damit unternimmt Microsoft den Versuch, das vormals von Unix herrührende NFS (Network File System) mit eigenen, universellen Protokollen zu ersetzen.

612

Virtuelle Unternehmensnetze via Internet

Hier muss berücksichtigt werden, dass Microsoft sein Client-Server-Protokoll SMB (Server Message Block) ebenfalls als »CIFS« (Common Internet File System) zu einem allgemeinen Standard werden ließ. Der Vorzug könnte sein:

23.4

Virtuelle Unternehmensnetze via Internet Demnächst könnten Unternehmensnetze über das Internet betrieben werden, insofern die verschiedenen Niederlassungen nicht mehr über eigene Wähl- oder Standleitungen zusammenkommen, sondern über öffentliche Leitungen. Alle Ressourcen, die LDAP unterstützen bzw. das Active Directory, könnten sich »sehen« und sich innerhalb des Domänen-Baums ansprechen. Die entsprechenden Vorteile lägen auf der Hand. Hier muss die Praxis zeigen, ob die Möglichkeiten tatsächlich gegeben sind bzw. ob die Technik zuverlässig läuft. In jedem Falle wird spätestens hier ein neues Thema von Belang: Verschlüsselung.

23.5

Verschlüsselung (A): Kerberos Wichtige Daten im Active Directory werden nunmehr nach dem Kerberos-Standard verschlüsselt. Damit soll ein zuverlässig hohes Niveau in der Sicherheit gegeben sein, es werden jedoch auch höhere Anforderungen an die Hardware gestellt.

23.6

Verschlüsselung (B): EFS Mit dem »Encrypting File System« (EFS) wird nunmehr die Daten-Vollverschlüsselung auf der Festplatte angeboten. Damit wird das Maß an Datensicherheit enorm gesteigert. Damit werden jedoch auch höhere Anforderungen an die Hardware gestellt.

23.7

PDC und BDC werden abgelöst Bislang musste jede Windows-NT-Domäne einen Zentral-Server haben, der die Benutzerdatenbank bzw. die Authentisierungsdaten enthielt. Dies war der Primary Domain Controller (PDC). Gegen Ausfall des PDC wurde die Domain geschützt durch den Betrieb eines Backup Domain Controllers (BDC). Diese Hierarchie von PDC-BDC ist mit Windows 2000 hinfällig.

Kapitel 23 • Ausblick: Windows 2000

613

Im Domänen-Baum sind die Domain Controller (so heißen sie weiterhin) als flach angeordnet zu betrachten. Sie tauschen weiterhin zur gegenseitigen Absicherung die Systemdatenbank des Domänen-Baums bzw. des Active Directory aus.

23.8

Replikationen / Partitionen Die Datenbank der Active Directories muss zwischen den Domain Controllern ausgetauscht - repliziert - werden. Während ein PDC in einer NT4-Domäne nur eine begrenzte Zahl von Rechnern, Ressourcen, Benutzern zu verwalten hatte, ist im Windows-2000-Baum damit zu rechnen, dass die Zahl der zu verwaltenden Objekte um ein Vielfaches größer sein wird – zum Beispiel dann, wenn die bisherige Struktur mit vielen, vielen NT4-Domänen aufgelöst und in eine einheitliche Windows-2000-Struktur überführt wird. Darum findet keine vollständige Übertragung der Systemdatenbank mehr statt; wenigstens wird empfohlen, dies durch Konfiguration zu vermeiden. Windows 2000 lässt die Unterteilung der Active Directory Systemdatenbank in sog. Partitionen zu. Die sog. Replikationen zwischen den Domain Controllern betrifft dann nur noch Teilbereiche der Systemdatenbank, nämlich diese Partitionen (Teileinheiten).

23.9

Vertrauensstellungen Domänen im Active Directory von Windows 2000 sind nahezu identisch mit denen von NT4. Verbindungen finden durch Vertrauensbeziehungen (Vertrauensstellungen) statt. Das Active Directory richtet Vertrauensstellungen aller enthaltenen Domains automatisch ein. Die Vertrauensstellungen sind also fester, selbstverständlicher Bestandteil von Active Directory. Darum gelten diese Vertrauensstellungen auch als »transitiv« bzw. »implizit«. Beispiel: Vertraut Domäne_A der Domäne_B und Domäne_C der Domäne_A, dann vertraut Domäne_C automatisch auch Domäne_B. »Volles Vertrauen« aller Domains ist mit Active Directory deutlich einfacher als bei NT4. Wenn n die Zahl der Domains ist, so verlangte NT4 n(n-1) Beziehungen, Active Directory nur n-1 Beziehungen. Bei vollen Vertrauensbeziehungen von 500 Domains hätte das bedeutet •

bei NT4 = 249.500 Vertrauensstellungen = 500(500-1);

•

bei Active Directory = 499 Vertrauensstellungen = 500-1.

Der Vorteil der neuen Technik ergibt sich also von selbst.

614

Mobile Computing / Follow Me

23.10 Mobile Computing / Follow Me Windows 2000 unterstützt in stärkerem Maße mobile Mitarbeiter, die sich an wechselnden Orten mit ihren Laptops ans Netz hängen. Es wird dabei das »Follow-Me«-Konzept verfolgt: Die Daten, Ressourcen und Konfigurationen sollen dem Anwender folgen – gleich, wohin. Lagen die Benutzerprofile früher nur auf einem WinNT-Server in nur einer Domäne, so sind sie jetzt netzwerkweit vorhanden und stehen darum dem Anwender überall zu Verfügung. Weiterhin können sog. »Offline-Ordner« spezifiziert werden, bei denen ein Synchronisieren, also ein Datenabgleich stattfindet, wenn der Anwender mit dem Laptop zur Heimarbeit nach Hause fuhr und nun wieder ins Unternehmen zurückkehrt.

23.11 IntelliMirror Der Begriff »IntelliMirror« steht •

für die umfassende, netzwerkweite Verwaltung von benutzerorientierten Daten sowie Anwendereinstellungen,

•

für die Unterstützung von Mobile Computing (Umzüge, Heimarbeit etc.),

•

für die Ausstattung der Benutzer mit überall denselben Rechten, Daten, Ressourcen.

Der Begriff »IntelliMirror« ist die Bezeichnung des Konzepts, mit dem Mobiles Computing und die Benutzerverwaltung über den gesamten Domänen-Baum hinweg bezeichnet wird.

23.12 Migration und Integration Das Active Directory ist abwärtskompatibel. Es kann mit Windows-2000-Servern die älteren NT-Server emulieren: •

Windows NT 3.51 + 4.0 Domains

•

Windows NT 3.51 + 4.0 PDCs (Primary Domain Controller)

Bisherige Windows NT Server (Versionen 3.51, 4) können weiter benutzt werden. Das Active Directory unterstützt darum NT-Admin-Tools mit Win32-API.

Kapitel 23 • Ausblick: Windows 2000

615

23.13 Mixed Mode Windows-2000-Server können für eine Übergangszeit im Mischbetrieb geführt werden; hierbei unterstützen sie die Win2000-Technik genauso wie die WinNT4Technik. Windows-2000-Server können sich demnach wie NT4-PDCs verhalten und somit die alten Domänen einbinden bzw. bedienen. Die alten NT4-Domänen-Datenbanken des PDC können in das Active Directory des Windows-2000/NT-Mischservers integriert werden. Unklar ist zum Redaktionsschluss, ob nun der Mixed Mode bei Windows-2000Servern von vornherein gegeben sein wird, oder ob er eigens konfiguriert werden muss. Hier hat es mehrfach einen Wechsel in der Meinung bei Microsoft und verschiedene Ankündigungen gegeben. Erst die offizielle Vorstellung des Produkts wird Klarheit schaffen. Deutlich wird jedoch der Wille von Microsoft, die Migration möglichst stark zu unterstützen. Sollte Microsoft jedoch den Mixed Mode per Voreinstellung aktivieren, dürfte jetzt schon klar sein, dass Konflikte und Fehler vorprogrammiert sind, da schon die alte NT4-Technik voll von Bugs war.

23.14 Ausblick Der Autor dieser Zeilen ist für seine teilweise beißende Kritik gegenüber Windows 95, 98 und NT bekannt. Er kann aber nicht abstreiten, dass das Konzept von Windows 2000 im Kern richtig und wichtig ist. Angesichts der WindowsNT4-Domänen-Technik waren die Neuerungen überfällig. Microsoft hat nicht nur zu Novell und dessen NDS (NetWare Directory Services) aufgeschlossen, sondern teilweise den Spurt zum Überholen begonnen. Das kann zunächst für die Anwender nur hilfreich sein, da die neuen Techniken deutlich verbesserte Möglichkeiten schaffen. Sollte Microsoft jedoch bei diesem stark verbreiterten Spektrum der Funktionen und Features dieselbe Fehleranfälligkeit in der Kommunikationsbasis aufweisen, so wird die nächste Auflage dieses Buches Schwierigkeiten haben, noch alles in einem einzigen Band unterzubringen. Die Schmerzen, die Anwender und Admins beim Weg von Windows NT durch die Versionen 3, 3.5 und 4 sowie durch die verschiedenen Service Packs zu erleiden hatten, sind unvergessen. Es ist pure Spekulation, ob Microsoft aus den Erfahrungen gelernt und die Einführung von Windows 2000 besser vorbereitet hat. Chance und Risiko liegen hier nur noch hauchdünn auseinander.

616

Messtechnik und Windows 2000

23.15 Messtechnik und Windows 2000 Auch die messtechnischen Implikationen werden dann wieder in den Mittelpunkt rücken – schließlich wird es wieder so sein, dass ernste Fehler nicht über die Systemsteuerung, sondern über den LAN-Analysator an der Leitung sowie über direkten Zugriff auf die Registry bzw. auf die Systemdatenbank des Active Directory zu knacken sein werden. Bei Beschaffungsentscheidungen sollte darum heute schon darauf geachtet werden, dass neue Protokolle wie LDAP unterstützt werden (etwa durch den LANdecoder32). Hierüber wird durch den Autor baldmöglichst berichtet, sobald die ersten Erfahrungen aus der Praxis vorliegen. Vorerst können die Leser den Autor zu Fragen des aktuellen Sachstandes per E-Mail erreichen: [email protected]

Anhang A Die Registry von Windows NT A.1 A.2 A.3 A.4 A.5 A.6 A.7 A.8 A.9 A.10 A.11 A.12 A.13 A.14 A.15 A.16 A.17 A.18 A.19 A.20 A.21 A.22 A.23 A.24 A.25 A.26 A.27 A.28 A.29

NetRules User Restrictions Service Provider / Name Space Provider TCP/IP Service Provider (WinSock) TCP/IP-Adapterparameter TCP/IP WinSock – AfD AppleTalk-Adapterparameter Browser / Suchdienst DHCP-Client DHCP Server DLC-Adapterparameter DNS DNS Zones InetInfo IP RIP LanMan Server MUP – Multiple UNC Provider NBF – NetBEUI Transport Frames NetBT – NetBIOS over TCP/IP NetBT-Adapter-Parameter NetLogon NwLnkIpx – NetWare Link IPX NwlnkNb – Novell NetBIOS Streams TCP/IP-Parameter TCP/IP Persistent Routes TCP/IP WinSock W3SVC – WWW Servivces WinSock

620 626 627 629 632 644 654 657 661 663 667 671 686 690 701 709 710 711 729 742 744 751 757 760 761 778 779 781 795

618

In diesem Anhang sind über 300 Registry-Parameter beschrieben, welche die Datenkommunikation von Windows NT steuern. Jeder Einzelne von ihnen kann unter Umständen dazu beitragen, dass Client-Server-Sessions nicht korrekt funktionieren. Es muss auf die beiden Kapitel »Windows Networking« und »TCP/IP / Die DoDProtokolle« verwiesen werden. Dort finden sich die realen Fehler bzw. Auswirkungen, die mit Registry-Parametern zusammenhängen können. Die hier beschriebenen Registry-Schlüssel beziehen sich auf die Datenkommunikation von Windows-NT. In den Kästen ist der Registry-Pfad mit allen Einträgen aufgeführt; nachfolgend werden die Einträge jeweils einzeln beschrieben. Die Beschreibungen beruhen auf folgenden Quellen: •

Microsoft Knowledge Base

•

Microsoft TechNet

•

Microsoft WinNT4 Resource Kit

•

Messtechnische Daten des Verfassers

Die Microsoft-Quellen sind sehr verteilt und im englischen Original oft sehr schwammig und sogar zum Teil äußerst missverständlich abgefasst. Der Verfasser dieses Buches (und damit Bearbeiter der Microsoft-Quellen) hat sich Mühe gegeben, Fehler zu korrigieren, Ungenauigkeiten zu beseitigen und Ergänzungen vorzunehmen, wo sie nötig waren. Dies wird z.B. im Abschnitt zu »NBF« (NetBEUI) deutlich, der einige erläuternde Zusatzabschnitte erhalten hat, um das teilweise schon ans Unverständliche grenzende Material von Microsoft zurechtzurücken. Die Auswahl wurde so getroffen, dass die meisten Registry-Einträge erfasst wurden, die für die LAN/WAN-Kommunikation von WinNT zuständig sind. Nicht erfasst wurden Spezialfälle wie z.B. RAS (Remote Access Server). Mit Ausnahme von »LanManServer« wurden die Registry-Schlüssel vollständig mit allen Parametern erfasst und beschrieben (so weit das eben möglich war). Die Reihenfolge der Auflistung entspricht der alphabetischen Reihenfolge der RegistryPfade. Registry-Schlüssel, die in diesem Anhang dokumentiert sind: HKEY_LOCAL_MACHINE\Software \Microsoft\[DriverName]\CurrentVersion\NetRules \Microsoft\[ServiceName]\CurrentVersion \Microsoft\Windows_NT\CurrentVersion\NetworkCards\NetCard#\NetRules Tab. A.1: Übersicht: Die beschriebenen Registry-Schlüssel

Anhang A • Die Registry von Windows NT

619

Registry-Schlüssel, die in diesem Anhang dokumentiert sind: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ \ServiceProvider\Order \Services\Tcpip\ServiceProvider HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ \AdapterName#\Parameters\Tcpip \Afd\Parameters \AppleTalk\Adapters\AdapterName \Browser\Parameters \DHCP\Parameters\Options\Option# \DHCPServer\Parameters \DLC\Parameters\AdapterName \DNS\Parameters \DNS\Parameters\Zones\Zone_name \InetInfo\Parameters \IpRip\Parameters \LanmanServer\Parameters \Mup \NBF\Parameters \NetBT\Adapters\[AdapterName] \NetBT\Parameters \Netlogon\Parameters \NwlnkIpx\NetConfig\Driver# \NwlnkNb\Parameters \Streams\Parameters \Tcpip\\Parameters \Tcpip\\Parameters\PersistentRoutes \Tcpip\\Parameters\Winsock \W3SVC\\Parameters \WinSock\\Parameters Tab. A.1: Übersicht: Die beschriebenen Registry-Schlüssel (Forts.)

Aus praktischen Gründen wurde der Name des Hauptschlüssels in den folgenden Auflistungen abgekürzt (ab A.2): HKEY_LM\ = HKEY_LOCAL_MACHINE\

620

A.1

NetRules

NetRules HKEY_LM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards\ NetCard#\NetRules HKEY_LM\Software\Microsoft\DriverName\CurrentVersion\NetRules Bindable bindform Class Hidden Interface Review type use Tab. A.2: Registry-Schlüssel für NetRules

Die Registry-Unterschlüssel »NetRules« enthalten Daten, die benötigt werden, um Netzwerkkomponenten an das System zu binden. Auf die Einträge von »NetRules« wird zugegriffen, wenn unter »Systemsteuerung/Netzwerk« die Netzwerkkonfiguration geändert wird. Die Registry enthält Unterschlüssel namens »NetRules« für Netzwerk-Adapterkarten, Netzwerk-Adaptertreiber und Netzwerkdienste. Statt »Microsoft« kann der Name eines anderen Herstellers im Registry-Path der »NetRules« stehen. Die im Folgenden beschriebenen Einträge von »NetRules« gelten sowohl für Netzwerk-Adapterkarten wie auch Netzwerk-Adaptertreiber und haben auch dieselbe Bedeutung (gleich, ob sie bei der Adapterkarte oder beim Adaptertreiber erscheinen). Für Netzwerk-Adaptertreiber und Netzwerkdienste stehen die NetRules im folgenden Registry-Pfad: HKEY_LM\Software\Microsoft\DriverName\CurrentVersion\NetRules

Für Netzwerk-Adapterkarten stehen die NetRules im folgenden Registry-Pfad: HKEY_LM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards\ NetCard#\NetRules

Wobei »NetCard#« für einen nummerierten, durchgezählten Eintrag für den jeweiligen Adapter steht. Werden Treiber und Adapter nicht von Microsoft geliefert, sondern von Drittherstellern, so wird der Name Microsoft ersetzt durch den Namen des Herstellers.

Anhang A • Die Registry von Windows NT

621

Um die Bindungen eines Rechners zu sehen, ist die Tabelle »Bindungen« in »Systemsteuerung/Netzwerk« zu öffnen.

bindable REG_MULTI_SZ

Class1 [Class2] [Criteria1] [Criteria2] …

Dieser Wert definiert eine gültige Bindung und ihre Parameter. Bindungen beschreiben das Verhältnis zwischen Netzwerkkomponente, darunter Netzwerkdienst, Transportpotokoll, Netzwerk-Adapterkarte und Netzwerk-Adaptertreiber. Bindungen, die über »bindable« festgelegt werden, gelten zusätzlich zu den voreingestellten Bindungsregeln. Bindungen gelten unabhängig davon, wo sie im System auftreten, für alle Netzwerkkomponenten, die sie betreffen. Beispiel: Der Wert von »bindable« für IEEPRO, den Treiber von »Intel EtherExpress PRO«, könnte wie folgt aussehen: eproDriver eproAdapter non exclusive 100

Diese Werte legen Folgendes fest: >

Komponenten in der Klasse (»class«) »eproDriver« können sich an solche der Klasse »eproAdapter« binden.

>

»Non« steht für »non-exclusive« (nicht ausschließlich, nicht alleinig) und zeigt an, dass die Komponenten in der Klasse eproDriver sich an die Komponenten anderer Klassen als der von eproAdapter binden können.

>

»Exclusive« (ausschließlich, alleinig) zeigt an, dass Komponenten der Klasse eproAdapter sich nur an Komponenten der Klasse eproDriver binden können.

>

»100« zeigt die relative Priorität an. Bei Konflikten zwischen Bindungen verwendet Windows NT diejenigen Bindungen mit der höchsten Priorität.

Tab. A.3: binable-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag entweder über einen Registry-Editor oder über sonstige geeignete Software vornehmen.

bindform REG_SZ ObjectName Yes|No Yes|No [container|simple|streams]

622

NetRules

Dieser Wert enthält Bindungsinformation für eine Komponente. Feld

Beschreibung

ObjectName

Speichert den Namen (oder das Namens-Vorderteil), den das System nutzt, um die Komponente zu identifizieren, zu dem die Bindung gehört. Dieser Wert muss übereinstimmen mit dem Namen im Unterschlüssel »CurrentControlSet\Services«, in dem Werte für diese Komponente gespeichert sind. Der ObjectName muss ebenfalls dem vom System erzeugten Namen für den Adapter entsprechen. Wenn die Werte unterschiedlich sind, geht der System-Name dem in »bindform« genannten Namen vor.

Yes|No (erstes Vorkommnis)

Legt fest, ob Bindungsinformation für diese Komponente in ihrem Unterschlüssel »Linkage« gespeichert wird.

Yes|No (zweites Vorkommnis)

Legt fest, ob der Gerätename in der erzeugten BindungsZeichenfolge (»binding string«) erscheint.

Container|simple |streams

Gibt an, wie sich die Bindungsnamen von Geräten/Komponenten zusammensetzen. Dieser Wert ist optional für Hardware-Komponenten, ist aber vorgeschrieben für SoftwareKomponenten.

Tab. A.4: Bindungsinformationen

Class REG_MULTI_SZ

NewClassName OldClassName|basic

[Yes|No]

Dieser Wert definiert eine neue Klasse für eine Komponente. »Yes|No« gibt an, ob diese Klasse ein logischer Endpunkt für die Bindung ist. Alle Bindungen müssen eine klare Endbegrenzung haben (»termination«), entweder an einem physikalischem Gerät oder an einem logischen Endpunkt, was ein Programm bezeichnet, das alle weitere Information der Verbindung (»interconnection«) handhabt. Dieser Teil des Wertes von »class« ist wahlfrei (optional). Ist dieser Teil im Wert von »class« nicht enthalten, geht das System davon aus, dass der Wert auf »No« steht. Klassennamen müssen nicht innerhalb der jeweiligen Komponente definiert werden. Das System legt die neue Definition in der Systemdatenbank ab ohne Bezug auf seine Herkunft. Weiterhin kann eine Komponente so viele neue Klassen definieren wie benötigt werden, und die Klassen können in beliebiger Reihenfolge definiert werden. In jedem Falle aber muss jede installierte Netzwerkkomponente einen einmaligen, eindeutigen Namen haben, und jede Klasse, auf die seitens der Komponente Bezug genommen wird, muss irgendwo im System definiert sein.

Anhang A • Die Registry von Windows NT

623

Dieser Eintrag bezieht sich auf Klassen von Netzwerkkomponenten. Diese Klassen stehen in keiner Weise in Verbindung mit COM-Objekt-Daten oder DD-Klassen, die in HKEY_LM\Software\Classes definiert sind.

Hidden REG_DWORD 0 | 1 Default: 0

Dieser Wert bestimmt, ob diese Komponente in der Komponentenliste in »Systemsteuerung/Netzwerk« erscheinen. In »Systemsteuerung/Netzwerk« gibt es Komponentenlisten für Dienste (»Services«), Protokolle (»Protocols«), und Adapter. Erscheint eine Komponente nicht in der jeweiligen Liste, können Anwender diese weder konfigurieren, noch entfernen. Wert

Bedeutung

0

Die Komponente erscheint in der Komponentenliste von »Systemsteuerung/ Netzwerk«.

1

Die Komponente erscheint nicht in der Komponentenliste von »Systemsteuerung/Netzwerk«.

Tab. A.5: hidden-Werte

Der Wert von »OperationsSupport« hat Vorrang vor dem Wert von »Hidden«. Wenn der Wert von »OperationsSupport« für die gegebene Komponente größer oder gleich 128 (0x80) ist, erscheint diese Komponente nicht in den Komponentenlisten von »Systemsteuerung/Netzwerk«, auch dann, wenn der Wert von »Hidden« auf »0« gesetzt ist. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

Interface REG_MULTI_SZ

InterfaceName

UpperClass

"ObjectName"

NamingMethod

Dieser Wert beschreibt eine zweite Schnittstelle (»secondary interface«), um damit eine Komponente für andere Komponenten des Systems verfügbar zu machen. Der Wert von »Interface« enthält folgende Felder:

624

NetRules

Feld

Bedeutung

InterfaceName

Der Name der Zweit-Schnittstelle in der Form eines Token.

UpperClass

Der Name der Klasse, zu der die Zweit-Schnittstelle gehört. (Der Name der Klasse der Erst-Schnittstelle ist im Wert von »type« angegeben.)

ObjectName

Der Gerätename (»device name«) von Windows NT, der durch den Eintrag des Wertes von »Interface« erzeugt wird.

NamingMethod

Gibt an, wie die Bindung erscheint.

Tab. A.6: Interface-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

Review REG_DWORD 0 | 1 Default: 0

Dieser Wert gibt an, ob die zur Komponente gehörige Informationsdatei (.inf) erneut herangezogen wird, wenn die Bindungen geändert werden. Ein solcher Vorgang des erneuten Heranziehens der Informationsdatei (.inf) versetzt Netzwerkkomponenten in die Lage, Bindungsinformation zu ändern und vom Administrator weitere Information zur aktuell bearbeiteten (neuen oder veränderten) Verbindung abzufragen. Wert

Bedeutung

0

NEIN: Die Informationsdatei (.inf) der Komponente wird nicht erneut herangezogen.

1

JA: Die Informationsdatei (.inf) wird jedesmal erneut herangezogen, wenn eine Bindung geändert wird.

Tab. A.7: Review-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

Anhang A • Die Registry von Windows NT

625

type REG_SZ

ComponentClassName

[LowerClass]

Dieser Wert gibt die Komponentenklasse einer Netzwerkkomponente an. Klassen-Name

Komponente

Adapter

Hardware-Komponente.

Driver

Eine Software-Komponente, die unmittelbar mit der HardwareKomponente verbunden ist.

Transport

Eine Software-Komponente, die von einem Dienst (»service«) verwendet wird.

Service

Eine Software-Komponente, die Benutzerapplikationen gegenüber ihre Eigenschaften bzw. Fähigkeiten zur Verfügung stellt.

Basic

Ein Token (Zugriffs- bzw. Sicherheitsschlüssel), der verwendet wird, um den grundlegenden Klassennamen darzustellen (das ist eine Klasse ohne eigene Vorgängerklasse: »no parent class«).

Tab. A.8: Type-Werte

Der Wert von »LowerClass« gibt an, ob die Klasse für eine Erst- oder Zweitschnittstelle gegeben ist (»primary or secondary interface«). Dieser Wert ist in der Regel wahlfrei (optional), aber vorgeschrieben für Netzwerkprogramme wie Treiber, Transportprotokolle und Netzwerk-Adapterkarten. Wenn für »LowerClass« kein Wert angegeben ist, wird der erste Typ (oder »upperclass type«) sowohl für »upper class« wie auch »lower class« verwendet.

use REG_SZ service|driver|transport|adapter [Yes|No] [Yes|No] Default: Software-Komponenten: service yes yes Hardware-Komponenten: adapter yes yes

Dieser Wert bestimmt die Rolle, die eine Komponente spielt, und gibt vor, ob Gruppennamen für Treiber und Transportprotokolle verwendet werden (»driver group names«, »transport group names«) anstelle von bestimmtenten Abhängigkeiten bzw. Bezügen der Treiber und Transporte (»instead of specific driver or transport dependencies«). Diese Werte veranlassen das System diese Bezüge bzw. Abhängigkeiten auf Grundlage der Gruppennamen zu erzeugen, nicht aufgrund der jeweiligen Dienstnamen (»to generate references to dependencies based upon their group names, not their specific service names«).

626

User Restrictions

Wert

Beschreibung

Service

Gibt vor, dass die Komponente End-Benutzerfunktionalität zur Verfügung stellt und vom Betriebssystem voll unterstützt wird. Wenn ein Dienst über keinerlei Bindungen verfügt, schreibt das System eine Warnung in das System-Log (einsehbar über die »Ereignisanzeige«).

Driver

Gibt vor, dass die Funktion der Komponente (für sich allein genommen) eine oder mehrere Netzwerk-Adapterkarten unterstützen soll. Wenn keine Bindungen erzeugt oder keine Bindungen vom Benutzer für den Treiber zugelassen wurden, wird dieser Treiber nicht geladen und es wird kein Fehler (bzw. keine Meldung) erzeugt.

Transport

Gibt vor, dass die Funktion der Komponente (für sich allein genommen) einen Dienst unterstützen soll. Wie bei einem Treiber, wird der Dienst nicht geladen, solange es nicht erforderlich ist. Wenn keine Bindungen eingerichtet oder keine Bindungen vom Benutzer für den Dienst zugelassen wurden, wird dieser Dienst nicht geladen und es wird kein Fehler (bzw. keine Meldung) erzeugt.

Tab. A.9: use-Werte

Die erste »Yes|No«-Option gibt an, ob Treiber-Gruppennamen verwendet werden anstelle gesonderter Treiber-Abhängigkeitsbeschreibungen (»driver dependencies«). Die zweite »Yes|No«-Option gibt an, ob Transport-Gruppennamen verwendet werden anstelle gesonderter Transport-Abhängigkeitsbeschreibungen (»driver dependencies«). Windows NT fügt diesen Werteeintrag nur in den »NetRules«-Unterschlüsseln von Software-Komponenten an.

A.2

User Restrictions HKEY_LM\Software\Microsoft\[ServiceName]\CurrentVersion HKEY_LM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards\ NetworkCard# OperationsSupport Tab. A.10: Registry- Schlüssel für User Restrictions

Benutzer-Beschränkungen in »Systemsteuerung/Netzwerk« Die Einstellungen dieses Abschnitts schränken den Zugriff des Anwenders auf »Systemsteuerung/Netzwerk« ein. Es muss berücksichtigt werden, dass die verschiedenen Einschränkungen in zwei verschiedenen Registry-Pfaden zu finden sind.

Anhang A • Die Registry von Windows NT

627

OperationsSupport REG_DWORD Bit-mapped value Default: (Es gibt keinen Vorgabewert für diesen Eintrag.)

Dieser Wert legt fest, ob ein Dienst (»Service«), ein Treiber, ein Transportprotokoll oder ein Gerät (»device«) in den Tabellen von »Systemsteuerung/Netzwerk« angezeigt wird. Ist dies der Fall - wenn also angezeigt wird -, legt dieser Wert fest, welche Schaltflächen (»buttons«) in den Tabellen von »Systemsteuerung/Netzwerk« verfügbar sind. Die Schaltflächen entscheiden darüber, ob der Anwender die Vorgänge Öffnen/Sehen, Löschen/Entfernen, Aktualisieren oder Eigenschaften-Ändern durchführen kann. Der Wert von »OperationsSupport« ist eine Bit-Map. Um die Optionen zu kombinieren, muss aus den jeweiligen Bit-Werten der gewünschten Option(en) die Summe gebildet werden. Beispiel: Wenn die Komponente erscheinen und alle Schaltflächen aktiv sein sollen, muss der Wert auf ’10000111« (135 bzw. 0x87) gesetzt werden. Bit

Dez. / Hex.

Bedeutung

1

1 / 0x01

Aktiviert den Button »Aktualisieren« (»Update«).

10

2 / 0x02

Aktiviert den Button »Eigenschaften« (»Properties«).

100

4 / 0x04

Aktiviert den Button »Entfernen« (»Remove«).

10000000

128 / 0x80

Führt den Namen der Komponente in der Liste auf.

Tab. A.11: OperationsSupport-Werte

Der Wert von »OperationsSuppert« hat Vorrang vor dem Wert von »Hidden«.

A.3

Service Provider / Name Space Provider HKEY_LM\System\CurrentControlSet\Control\ServiceProvider\Order ExcludedProviders ProviderOrder Tab. A.12: Registry-Schlüssel für Service Provider / Name Space Provider

ServiceProvider\Order Subkey for Windows Sockets Diese Schlüsselwerte werden verwendet von den APIs der »Windows Sockets Service Resolution and Registration« (RNR).

628

Service Provider / Name Space Provider

ExcludedProviders REG_MULTI_SZ Name space provider number[ Name space provider number…] Default: (leerer Wert)

Gibt die »Name Space Provider« an (Netzwerkdienste, welche Namen verwenden), die *nicht* bei Namensauflösungen berücksichtigt werden sollen. Um einen »Name Space Provider« auszuschließen, wird die Nummer des betroffenen »Name Space Providers« mit seiner Dezimalnummer (s.u.) in die Tabelle eingetragen; die Tabelle besteht aus einem oder mehreren Werten, die jeweils mit Leerzeichen getrennt sind. Nummer

Name Space Provider

1

NS_SAP

2

NS_NDS

10

NS_TCPIP_LOCAL

11

NS_TCPIP_HOSTS

12

NS_DNS

13

NS_NETBT

14

NS_WINS

20

NS_NBP

30

NS_MS

31

NS_STDA

32

NS_CAIRO

40

NS_X500

41

NS_NIS

Tab. A.13: ExcludedProviders-Werte

Die Liste der »Name Space Providers« wird von Zeit zu Zeit erweitert bzw. aktualisiert. Die hier gezeigte Tabelle ist daher möglicherweise nicht aktuell bzw. unvollständig.

ProviderOrder REG_MULTI_SZ Registry subkey[ Registry subkey…] Default: (Variiert in Abhängigkeit von den installierten Protokollen)

Anhang A • Die Registry von Windows NT

629

Die »ProviderOrder« enthält die Registry-Unterschlüssel von »Name Space Provider« entsprechend der Reihenfolge, in welcher diese verwendet werden (sollen). Die Unterschlüssel sind im »Services«-Schlüssel enthalten. Beispiel: Wenn der Wert »Tcpip« ist, werden für den »Name Space Provider« TCP/IP die Werte aus HKEY_LM\System\CurrentControlSet\Services\Tcpip herangezogen. Um als gültiger Provider erkannt werden zu können, muss der Unterschlüssel einen »ServiceProvider«-Unterschlüssel enthalten unter Einschluss der Werte für »Class« und »ProviderPath«. Änderungen an diesem Schlüsselwert können dazu führen, dass im Netzwerk nicht mehr auf (bestimmte) Daten zugegriffen werden kann. Vor Änderungen ist daher zu warnen.

A.4

TCP/IP Service Provider (WinSock) HKEY_LM\System\CurrentControlSet\Control\Services\Tcpip\ServiceProvider Class DnsPriority HostsPriority LocalPriority Name NetbtPriority ProviderPath ProviderPath Tab. A.14: Registry-Schlüssel für TCP/IP ServiceProvider

TCP/IP – Service Provider for Windows Sockets Der Unterschlüssel »Tcpip\ServiceProvider« speichert die Werte, die zwecks Namensauflösung von den API-Funktionen »GetHostByName()« und »GetAddressByName()« verwendet werden.

Class REG_DWORD Default: 8

630

TCP/IP Service Provider (WinSock)

Zeigt an, dass TCP/IP ein »Name Space Provider« ist. Von Änderungen wird abgeraten.

DnsPriority REG_DWORD Priority Default: 0x7D0 (2000)

Gibt die relative Priorität an, die DNS hat, wenn es als Mechanismus zur Namensauflösung verwendet wird. Der Wert von »DnsPriority« wird verglichen mit den Werten »LocalPriority«, »HostsPriority« und »NetbtPriority«. Die Mechanismen zur Namensauflösung werden in der Reihenfolge ihrer Priorität aufgerufen. Um die Reihenfolge der Priorität zu ändern, ist ihre relative Priorität entsprechend anzupassen. Weil Werte kleiner als 0x3E9 (=1.000) für »schnelle« Namensauflösungen vorgesehen sind, erzeugen Werte kleiner 1.000 bei Namensauflösungen, die über das Netzwerk arbeiten (wie DNS und NetBT), möglicherweise unerwünschte Wirkungen.

HostsPriority REG_DWORD Default: 0x1F4 (500)

Dieser Wert gibt die relative Priorität des Host-Computers vor, wenn dieser als Mechanismus zur Namensauflösung eingetragen ist. Der Wert von »HostsPriority« wird verglichen mit den weiteren Werten »LocalPriority«, »DnsPriority« und »NetbtPriority«. Die Mechanismen zur Namensauflösung werden aufgerufen in der Reihenfolge ihrer Priorität. Um die Reihenfolge der Priorität zu ändern, ist ihre relative Priorität entsprechend anzupassen.

LocalPriority REG_DWORD Default: 0x1F3 (499)

Dieser Wert gibt die relative Priorität des lokalen Computers vor, wenn dieser als Mechanismus zur Namensauflösung eingetragen ist. Der Wert von »LocalPriority« wird verglichen mit den weiteren Werten »HostsPriority«, »DnsPriority« und »NetbtPriority«. Die Mechanismen zur Namensauflösung werden aufgerufen

Anhang A • Die Registry von Windows NT

631

in der Reihenfolge ihrer Priorität. Um die Reihenfolge der Priorität zu ändern, ist ihre relative Priorität entsprechend anzupassen.

Name REG_SZ Transport service name Default: TCP/IP

Gibt den Namen des Transport-Services (Transportprotokolls) an. Dieser Wert sollte nicht geändert werden.

NetbtPriority REG_DWORD Priority Default: 0x7D1 (2001)

Gibt die relative Priorität an, die NetBT hat, wenn es als Mechanismus zur Namensauflösung verwendet wird. Der Wert von »NetbtPriority« wird verglichen mit den Werten »LocalPriority«, »HostsPriority« und »DnsPriority«. Die Mechanismen zur Namensauflösung werden aufgerufen in der Reihenfolge ihrer Priorität. Um die Reihenfolge der Priorität zu ändern, ist ihre relative Priorität entsprechend anzupassen. Weil Werte kleiner als 0x3E9 (=1.000) für »schnelle« Namensauflösungen vorgesehen sind, erzeugen Werte kleiner 1.000 bei Namensauflösungen, die über das Netzwerk arbeiten (wie DNS und NetBT), möglicherweise unerwünschte Wirkungen.

ProviderPath REG_SZ Path and file name Default: %SystemRoot%\System32\wsock32.dll

Gibt den Pfad und Datennamen jener Dynamic Link Library (DLL) an, welche für TCP/IP die Namensauflösung betreibt. Dieser Wert sollte nicht geändert werden.

632

A.5

TCP/IP-Adapterparameter

TCP/IP-Adapterparameter HKEY_LM\System\CurrentControlSet\Services\AdapterName#\Parameters\ Tcpip DefaultGateway DhcpDefaultGateway DhcpIPAddress DhcpServer DhcpSubnetMask DhcpSubnetMaskOpt DontAddDefaultGateway EnableDhcp IPAddress IPInterfaceContext Lease LeaseObtainedTime LeaseTerminatesTime LLInterface MaxForwardPending MTU PPTPFiltering RawIPAllowedProtocols SubnetMask T1 T2 TcpAllowedPorts UdpAllowedPorts UseZeroBroadcast Tab. A.15: Registry-Schlüssel für TCP/IP-Adapterparameter

Adapter Card Parameters for TCP/IP Der Unterschlüssel »AdapterName#\Parameters\Tcpip« enthält Parameter für TCP/IP, die für einen bestimmten Netzwerkadapter gelten sollen. Die hier gespeicherten Werte beinhalten auch jene, die vom DHCP-Dienst (Dynamic Host Configuration Protocol) der Adapterkarte zugewiesen wurden.

DefaultGateway REG_MULTI_SZ IP address[ IP address…] Default: (leerer Wert)

Anhang A • Die Registry von Windows NT

633

Dieser Schlüsselwert gibt eines oder mehrere Gateways (Router) an, über die Pakete vermittelt werden sollen, wenn das Zielnetz nicht mit dem lokalen Subnetz identisch ist, in welchem der Absender angeschlossen ist, und wenn keine festgelegte bzw. vorgegebene Route existiert. Diese Einstellung wird von zwei Schlüsselwerten kontrolliert: »DhcpDefaultGateway« (vorgegeben von DHCP) und »DefaultGateway« – Letzteres kann vom Anwender geändert werden. Wenn der Wert von »DefaultGateway« eine oder mehrere IP-Adressen enthält, gehen diese den - möglichen - DHCP-Einstellungen vor. Dieser Wert wird der Registry hinzugefügt, wenn in der Windows-Systemsteuerung unter »Netzwerk« die Einstellungen für TCP/IP vorgenommen werden. Darum sollte für Änderungen dieses Wertes die Systemsteuerung verwendet werden. Siehe auch: PersistentRoutes

DhcpDefaultGateway REG_MULTI_SZ IPAddress[ IPAddress…] Default: (für diesen Eintrag gibt es keinen Vorgabewert)

Dieser Schlüsselwert gibt eines oder mehrere Gateways (Router) an, über die Pakete vermittelt werden sollen, wenn das Zielnetz nicht mit dem lokalen Subnetz identisch ist, in welchem der Absender angeschlossen ist, und wenn keine festgelegte bzw. vorgegebene Route existiert. Diese Einstellung wird von zwei Schlüsselwerten kontrolliert: »DhcpDefaultGateway« (vorgegeben von DHCP) und »DefaultGateway« – Letzteres kann vom Anwender geändert werden. Wenn der Wert von »DefaultGateway« eine oder mehrere IP-Adressen enthält, gehen diese den - möglichen - DHCP-Einstellungen vor. Dieser Eintrag wird vom DHCP-Client-Dienst erzeugt (sofern dieser aktiv ist). Dieser Eintrag sollte nicht geändert werden. Siehe auch: PersistentRoutes

DhcpIPAddress REG_SZ IPAddress[ IPAddress…] Default: (für diesen Eintrag gibt es keinen Vorgabewert)

634

TCP/IP-Adapterparameter

Gibt die IP-Adresse des Netzwerkadapters an. Dieser Eintrag wird kontrolliert von zwei anderen Einträgen: »DhcpIPAddress« (konfiguriert von DHCP) und IPAddress – Letzterer kann vom Anwender geändert werden. Wenn der Eintrag für »IPAddress« eine oder mehrere IP-Adressen enthält, gehen diese - möglichen - Werten von »DhcpIPAddress« vor. Dieser Eintrag wird vom DHCP-Client-Dienst erzeugt (sofern dieser aktiv ist). Dieser Eintrag sollte nicht geändert werden.

DhcpServer REG_SZ IPAddress[ IPAddress…] Default: (für diesen Eintrag gibt es keinen Vorgabewert)

Gibt die IP-Adresse des DHCP-Servers an, welcher die IP-Adresse des Netzwerkadapters vorgab. Die von DHCP konfigurierte IP-Adresse ist gespeichert in »DhcpIPAddress«. Dieser Eintrag wird vom DHCP-Client-Dienst erzeugt (sofern dieser aktiv ist). Dieser Eintrag sollte nicht geändert werden.

DhcpSubnetMask REG_SZ Subnet Mask Default: (für diesen Eintrag gibt es keinen Vorgabewert)

Gibt die von DHCP vorgegebene Subnetz-Maske vor für die IP-Adresse, welche in »DhcpIPAddress« abgelegt ist. Dieser Eintrag wird kontrolliert von zwei anderen Einträgen: »DhcpSubnetMask« (konfiguriert von DHCP) und »SubnetMask« – Letzterer kann vom Anwender geändert werden. Wenn der Wert von »SubnetMask« nicht auf 0.0.0.0 steht, geht der Wert von »SubnetMask« dem von »DhcpSubnetMask« vor. Dieser Eintrag wird vom DHCP-Client-Dienst erzeugt (sofern dieser aktiv ist). Dieser Eintrag sollte nicht vom Anwender geändert werden.

DhcpSubnetMaskOpt REG_MULTI_SZ SubnetMask Default: (für diesen Eintrag gibt es keinen Vorgabewert)

Anhang A • Die Registry von Windows NT

635

Gibt die Subnetz-Maske für eine etwaige DHCP-Option an. Konfigurationsdaten der DHCP-Option sind abgelegt in HKEY_LM\System\CurrentControlSet\Dhcp\Parameters\Options\Option#.

Der Pfad zu diesem Eintrag ist abgelegt im Wert des Eintrages »RegLocation«.

DontAddDefaultGateway REG_DWORD 0 | 1 Default: 0

Deaktiviert die vorgegebene Netzwerk-Adapterroute, die mit der Installation von PPTP eingetragen wurde. Wenn die Vorgaberoute deaktiviert wird, kann die Konfiguration von statischen Routen notwendig werden für Rechner, die über Router erreicht werden, die nicht mit dem Default_Gateway identisch sind. Wert

Bedeutung

0

JA – Das System installiert für jeden LAN-Adatper eine Default Route.

1

NEIN – Default Routes werden nicht verwendet.

Tab. A.16: DontAddDefaultGateway-Werte

Dieser Eintrag wird erst ab Windows NT 4.0 (oder später) unterstützt. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. PPTP-Anwender müssen diesen Eintrag vornehmen für jeden Netzwerkadapter, der nicht ans Internet angeschlossen ist. Siehe auch: RAS PPTPE Subkey Entries.

EnableDhcp REG_DWORD 0 | 1 Default: 0

Gibt vor, ob der DHCP-Dienst aktiviert ist. Ist der Wert 1, so versucht der DHCPClient die erste IP-Schnittstelle des gegebenen Adapters über DHCP einzustellen.

636

TCP/IP-Adapterparameter

Wert

Bedeutung

0

DHCP = AUS

1

DHCP = EIN

Tab. A.17: EnableDhcp-Werte

Dieser Eintrag wird der Registry hinzugefügt, wenn in der Systemsteuerung\ Netzwerk TCP/IP konfiguriert wird. Für Änderungen sollte die Systemsteuerung verwendet werden.

IPAddress REG_MULTI_SZ IPAddress[(ENTER-Taste)IPAddress] Default: 0.0.0.0

Gibt die IP-Adresse an des IP-Interfaces, das auf den Adapter gebunden ist. Diese Einstellungen werden von zwei anderen Werten kontrolliert: »DhcpIPAddress« (eingestellt durch DHCP) und »IPAddress« – Letzteres kann vom Anwender eingetragen werden. Wenn der Wert von »IPAddress« aus einer oder mehreren IP-Adressen (ungleich 0.0.0.0) besteht, so geht/gehen diese dem Wert in »DhcpIpAddress« vor. Für jede IP-Adresse muss eine gültige IP-Subnet-Mask vorhanden sein. Dieser Eintrag wird der Registry hinzugefügt, wenn in der Systemsteuerung\ Netzwerk TCP/IP konfiguriert wird. Für Änderungen sollte die Systemsteuerung verwendet werden.

IPInterfaceContext REG_DWORD 0x0-0xFFFFFFFF Default: (für diesen Eintrag gibt es keinen Vorgabewert)

Dieser Wert wird vom TCP/IP-Treiber angelegt zur Verwendung durch den DHCP-Client-Dienst. Der Wert dieses Eintrages sollte nicht durch den Anwender geändert werden.

Anhang A • Die Registry von Windows NT

637

Lease REG_DWORD 0x1-0xFFFFFFFF Sekunden Default: (für diesen Eintrag gibt es keinen Vorgabewert. Dieser Wert wird durch das System berechnet mittels der Lease-Zeit.)

Gibt an, wie lange das Lease (die zeitliche Vergabe) der IP-Adresse für diesen Adapter gültig ist. Dieser Eintrag wird durch den DHCP-Client-Dienst angelegt und verwaltet, sobald der Dienst aktiviert wird. Dieser Eintrag sollte nicht durch den Anwender geändert werden.

LeaseObtainedTime REG_DWORD Time (in Sekunden) ab 12:00 mittags des 1.Jan.1970 Default: (für diesen Eintrag gibt es keinen Vorgabewert. Dieser Wert wird durch das System berechnet mittels der Lease-Zeit.)

Hält die Zeit fest, wann das Lease (die zeitliche Vergabe) der IP-Adresse für diesen Adapter stattfand. Dieser Eintrag wird durch den DHCP-Client-Dienst angelegt und verwaltet, sobald der Dienst aktiviert wird. Dieser Eintrag sollte nicht durch den Anwender geändert werden.

LeaseTerminatesTime REG_DWORD Time (in Sekunden) ab 12:00 mittags des 1.Jan.1970 Default: (für diesen Eintrag gibt es keinen Vorgabewert. Dieser Wert wird durch das System berechnet mittels der Lease-Zeit.)

Hält die Zeit fest, wann das Lease (die zeitliche Vergabe) der IP-Adresse für diesen Adapter ausläuft. Dieser Eintrag wird durch den DHCP-Client-Dienst angelegt und verwaltet, sobald der Dienst aktiviert wird. Dieser Eintrag sollte nicht durch den Anwender geändert werden.

638

TCP/IP-Adapterparameter

LLInterface REG_SZ Device name Default: (für diesen Eintrag gibt es keinen Vorgabewert.)

Gibt den Namen der Windows-NT-Komponente an, an welche IP gebunden werden soll. Dieser Eintrag wird von Diensten verwendet wie RAS oder Direct-IP, sofern ein anderes Link-Layer-Protokoll verwendet werden soll als das interne ARP-Modul. Dieser Eintrag wird durch den DHCP-Client-Dienst angelegt und verwaltet, sobald der Dienst aktiviert wird. Dieser Eintrag sollte nicht durch den Anwender geändert werden.

MaxForwardPending REG_DWORD 0x1-0xFFFFFFFF packets Default: 0x14 (20)

Dieser Wert gibt die maximale Anzahl von IP-Paketen an, die von der Forwarding Engine (Routing Engine) gleichzeitig an eine einzelne Netzwerk-Schnittstelle übergeben werden darf. Wenn die tatsächliche Zahl der Pakete den Wert dieses Eintrags übertrifft, werden die überzähligen Pakete in eine Warteschlange verlegt, bis die beim Netzwerkadapter zur Übertragung anstehenden Pakete gesendet sind. Der optimale Wert für diesen Eintrag hängt von Art und Anzahl der verfügbaren Leitungen ab. Für gewöhnlich ist der hier gegebene Wert ausreichend bzw. wirkungsvoll, insbesondere bei schnellen LAN-Adaptern. Gleichwohl kann in einzelnen Fällen ein Heraufsetzen dieses Wertes z.B. bei RAS-Schnittstellen helfen, die mehrere langsame serielle Leitungen bedienen. Dieser Eintrag wird erst unterstützt ab Windows NT 3.51 Service Pack 2 (oder später). Windows NT legt diesen Eintrag nicht selber an. Der Anwender kann dies tun über den Registry-Editor oder ein anderes entsprechendes Programm.

MTU REG_DWORD 0x44 – MTU of the underlying network (bytes) | 0xFFFFFFFF Default: 0xFFFFFFFF

Anhang A • Die Registry von Windows NT

639

Legt die »Maximum Transmission Unit« (MTU) für eine Netzwerk-Schnittstelle fest. Bei der MTU handelt es sich um die maximale Paketgröße, mit der gesendet wird. Wert

Bedeutung

0x44 (68 bytes) – MTU des darunter liegenden liegenden Netzwerkes

Gibt die MTU des verwendeten Netzwerkadapters an. Dieser Wert geht der MTU des darunter liegenden Netzwerkes vor.

0xFFFFFFFF (oder größer als die MTU des darunter liegenden Netzwerkes)

Das System fragt den Treiber des Netzwerkadapters ab und verwendet den MTU-Wert, der vom Adaptertreiber zurückgegeben wird.

Tab. A.18: MTU-Werte

Die MTU ist die maximale Paketgröße (in Bytes), die vom darunter liegenden Netzwerk unterstützt wird. Die Paketgröße beinhaltet die Größe des TransportHeaders. Ein IP-Datagramm kann sich über mehrere Pakete verteilen (IP Fragmenting). Jede Schnittstelle, die von TCP/IP verwendet wird, kann einen anderen Wert für die MTU haben. Idealerweise sollte die MTU groß genug gewählt sein, um ein einzelnes IP-Datagramm mit nur einem einzigen Datenpaket zu versenden (ohne IP Fragmenting). Die tatsächliche Begrenzung der MTU liegt in der physikalischen Paketgröße des Netzwerkmediums (z.B. Ethernet oder Token-Ring). Einige Techniken kennen Begrenzungen sogar auf nur 128 Byte (z.B. kann X.25 so arbeiten); Ethernet hat seine Grenze bei einer MTU von 1.500 Bytes; andere Techniken wie Token-Ring oder FDDI verwenden größere MTUs. IP-Datagramme, die größer sind als die unterstützte MTU, werden automatisch in kleinere Einheiten zerlegt, die »Fragmente« genannt werden, deren Größe jeweils aus einem Mehrfachen von jeweils 8 Bytes besteht. IP-Fragmentation findet statt, wenn ein eingegangenes IP-Paket größer ist als die unterstützte MTU auf dem Ausgangsadapter. Die Fragmente laufen selbstständig und unabhängig durchs Netzwerk, bis sie wieder zusammengesetzt werden. Üblicherweise findet IP-Fragmenting nur statt zwischen IP-Routern; findet sie zwischen IP-Endgeräten statt, liegt meistens ein Konfigurations- oder Applikationsfehler vor. Windows NT fügt diesen Eintrag nicht selber in die Registry ein. Dies kann der Anwender tun mit dem Registry-Editor oder anderen Programmen. Die Vorgabe ist, dass Windows NT TCP/IP das »PMTU Discovery« verwendet, wobei am Treiber des Netzwerkadapters die physikalische MTU abgefragt wird. Daher ist eine manuelle Änderung des aktuellen Registry-Eintrags nicht notwendig bzw. kann sogar die Sendeleistung beeinträchtigen.

640

TCP/IP-Adapterparameter

Im Einzelfall sollte in der Microsoft Knowledge Base nach aktuellen Auskünften zu »PMTU« gesucht werden: http://www.microsoft.com/kb .

PPTPFiltering REG_DWORD 0 | 1 Default: 0

Dieser Eintrag gibt an, ob das PPTP-Filtering am gegebenen Adapter aktiviert ist. PPTP-Filtering hat den Zweck, das System vor schädlichen Angriffen zu schützen, insbesondere dann, wenn der Adapter an ein öffentliches Netz wie das Internet angeschlossen ist. Wert

Bedeutung

0

Deaktiviert das Filtern.

1

Aktiviert das Filtern. Der Adapter akzeptiert nur noch PPTP-Verbindungen.

Tab. A.19: PPTPFiltering-Werte

Dieser Eintrag wird erst ab Windows NT 4.0 (oder später) unterstützt. Dieser Eintrag wird über die Systemsteuerung\Netzwerk eingetragen bzw. verändert.

RawIPAllowedProtocols REG_MULTI_SZ Default: 0

0 | IP protocol numbers

Gibt die Nummern der IP-Protokolle an, die bei empfangenen IP-Paketen akzeptiert werden, wenn das »Security Filtering« aktiviert ist. Dieses ist der Fall, wenn der Wert für »EnableSecurityFilters« auf 1 gesetzt ist. Der Wert dieses Eintrages »RawIPAllowedProtocol« gibt an, welche IP-Datagramme vom »raw IP transport« (rohen bzw. puren IP-Transport) mit »raw sockets« akzeptiert werden. Dies hat keine Auswirkungen auf IP-Datagramme, die zu anderen Transportprotokollen weitergereicht werden, etwa TCP. Der Wert dieses Eintrag betrifft alle IP-Schnittstellen, die auf dem gegebenen Adapter konfiguriert sind.

Anhang A • Die Registry von Windows NT

Wert

641

Bedeutung

0 (oder in der Registry nicht vorhanden)

Alle IP-Datagramme werden akzeptiert.

Leerer Wert (Der Eintrag ist in der Registry vorhanden, enthält aber keine Daten bzw. keinen Wert.)

Es werden keine Datagramme akzeptiert.

Specifische IP-Protokollnummern

Nur Datagramme mit dieser IP-Protokollnummer werden akzeptiert.

Tab. A.20: RawIPAllowedProtocols-Werte

Das »Internet Protokoll« (IP) enthält einen Parameter, mit dem das nächste, nachfolgende Protokoll innerhalb des Stapels bzw. innerhalb des IP-Datagramms gekennzeichnet wird; an dieses Protokoll muss IP die übertragenen Daten weiterreichen. Diese Protokollkennung innerhalb von IP heißt treffend »Protocol« oder »Protocol ID«. Dieser Eintrag wird erst ab Windows NT 4.0 (oder später) unterstützt. Dieser Eintrag wird über die Systemsteuerung\Netzwerk eingetragen bzw. verändert. Es gibt keine zuverlässige Aussage darüber, wie sich das System verhält, wenn der Eintrag als Wert sowohl eine Null wie auch eine IP-Protokollnummer enthält. Darum sollte diese Kombination vermieden werden.

SubnetMask REG_MULTI_SZ IP address[ IP address…] Default: (für diesen Eintrag gibt es keinen Vorgabewert.)

Dieser Eintag gibt den Wert für die Subnetz-Maske an, gültig für die IP-Schnittstelle, die auf dem gegebenen Adapter gebunden ist. Es muss ein gültiger Wert für die Subnet Mask vorhanden sein für jede einzelne IP-Adresse, die im Eintrag »IPAddress« eingetragen ist. Dieser Eintrag wird kontrolliert von zwei anderen Einträgen: »DhcpSubnetMask« (konfiguriert von DHCP) und »SubnetMask« – letzterer kann vom Anwender geändert werden. Wenn der Wert von »SubnetMask« nicht auf 0.0.0.0 steht, geht der Wert von »SubnetMask« dem von »DhcpSubnetMask« vor. Dieser Eintrag wird vom DHCP-Client-Dienst erzeugt (sofern dieser aktiv ist). Dieser Eintrag sollte nicht vom Anwender geändert werden. Dieser Eintrag wird über die Systemsteuerung\Netzwerk eingetragen bzw. verändert.

642

TCP/IP-Adapterparameter

T1 REG_DWORD Time (in Sekunden) ab 12:00 mittags des 1.Jan.1970 Default: (für diesen Eintrag gibt es keinen Vorgabewert)

Dieser Eintrag gibt vor, wann der DHCP-Dienst versuchen wird/soll, das IPLease (die zeitliche Überlassung der IP-Adresse) für den gegebenen Adapter bei jenem DHCP-Server zu erneuern, der das IP-Lease gab. Ist der Versuch nicht erfolgreich, sendet der DHCP-Dienst Broadcast-Meldungen mit Erneuerungsanfragen; der Zeitwert hierzu ist im Eintrag »T2« festgelegt. Dieser Eintrag wird vom DHCP-Client-Dienst erzeugt (sofern dieser aktiv ist). Dieser Eintrag sollte nicht geändert werden.

T2 REG_DWORD Time (in Sekunden) ab 12:00 mittags des 1.Jan.1970 Default: (für diesen Eintrag gibt es keinen Vorgabewert.)

Dieser Eintrag gibt an, wann der DHCP-Dienst versuchen wird/soll, eine Erneuerung des IP-Leases (der zeitweisen Überlassung bzw. Vergabe der IP-Adresse) via Broadcast durchzuführen. Dieser Eintrag kommt nur zum Tragen, wenn der DHCP-Dienst vergeblich versucht hat (gemäß Timer T1) die Erneuerung an jenem DHCP-Server durchzuführen, der das erste IP-Lease gab. Dieser Eintrag wird vom DHCP-Client-Dienst erzeugt (sofern dieser aktiv ist). Dieser Eintrag sollte nicht geändert werden.

TcpAllowedPorts REG_MULTI_SZ Default: 0

0 | TCP port numbers

Dieser Eintrag nennt die TCP Port-Nummern (TCP Sockets), bei denen eingehende TCP-SYNs akzeptiert werden, wenn die IP-Schnittstelle das »IP Filtering« verwendet; dieses ist der Fall, wenn »EnableSecurityFilters« auf 1 gesetzt ist; dieser Wert gilt dann für alle IP-Schnittstellen auf dem gegebenen Adapter.

Anhang A • Die Registry von Windows NT

Wert

643

Bedeutung

0 (oder nicht in Registry vorhanden)

Alle TCP-SYNs werden akzeptiert.

Leerer Wert. (Der Eintrag ist vorhanden, enthält aber keine Daten bzw. keinen Wert.)

Keine TCP-SYNs werden akzeptiert.

Spezifische TCP-Port-Nummern

Nur TCP-SYNs mit diesen TCP-PortNummern werden akzeptiert.

Tab. A.21: TcpAllowedPorts-Werte

Dieser Eintrag wird erst ab Windows NT 4.0 (oder später) unterstützt. Dieser Eintrag wird über die Systemsteuerung\Netzwerk eingetragen bzw. verändert. Es gibt keine zuverlässige Aussage darüber, wie sich das System verhält, wenn der Eintrag als Wert sowohl eine Null wie auch eine TCP-Port-Nummer enthält. Darum sollte diese Kombination vermieden werden.

UdpAllowedPorts REG_MULTI_SZ Default: 0

0 | UDP port numbers

Dieser Eintrag nennt die UDP Port-Nummern (UDP Sockets), bei denen eingehende Datagramme akzeptiert werden, wenn die IP-Schnittstelle das »IP Filtering« verwendet; dieses ist der Fall, wenn »EnableSecurityFilters« auf 1 gesetzt ist; dieser Wert gilt dann für alle IP-Schnittstellen auf dem gegebenen Adapter. Wert

Bedeutung

0 (oder nicht in Registry vorhanden)

Alle UDP-Datagramme werden akzeptiert.

Leerer Wert. (Der Eintrag ist vorhanden, enthält aber keine Daten bzw. keinen Wert.)

Keine UDP-Datagramme werden akzeptiert.

Spezifische UDP-Port-Nummern

Nur Datagramme mit diesen UDP-Ports werden akzeptiert.

Tab. A.22: UdpAllowedPorts-Werte

Dieser Eintrag wird erst ab Windows NT 4.0 (oder später) unterstützt. Dieser Eintrag wird über die Systemsteuerung\Netzwerk eingetragen bzw. verändert.

644

TCP/IP WinSock – AfD

Es gibt keine zuverlässige Aussage darüber, wie sich das System verhält, wenn der Eintrag als Wert sowohl eine Null wie auch eine UDP-Port-Nummer enthält. Darum sollte diese Kombination vermieden werden.

UseZeroBroadcast REG_DWORD 0 | 1 Default: 0

Dieser Eintag gibt vor, ob IP seine IP-Broadcast-Adresse binär aus Nullen oder Einsen bildet. Die meisten Systeme verwenden Einser-Broadcasts; einige Ausnahmen jedoch (z.B. die von BSD abgeleiteten Implementationen) verwenden Nuller-Broadcasts. Systeme, die unterschiedliche IP-Broadcasts verwenden, werden nicht miteinander via IP kommunizieren können, oder zumindest nicht zuverlässig. Wert

Bedeutung

0

Die Broadcasts werden binär aus »1111....« gebildet. Die lokale IP Broadcast Address ist 255.255.255.255

1

Die Broadcasts werden binär aus »0000....« gebildet. Die lokale IP Broadcast Address ist 0.0.0.0.

Tab. A.23: UseZeroBroadcast-Werte

A.6

TCP/IP WinSock – AfD HKEY_LM\System\CurrentControlSet\Services\Afd\Parameters BufferMultiplier DefaultReceiveWindow DefaultSendWindow DynamicBacklogGrowthDelta EnableDynamicBacklog FastSendDatagramThreshold IgnorePushBitOnReceives InitialLargeBufferCount InitialMediumBufferCount InitialSmallBufferCount IrpStackSize LargeBufferSize MaximumDynamicBacklog Tab. A.24: Registry- Schlüssel für AfD – WinSock

Anhang A • Die Registry von Windows NT

645

HKEY_LM\System\CurrentControlSet\Services\Afd\Parameters MediumBufferSize MinimumDynamicBacklog PriorityBoost SmallBufferSize StandardAddressLength TransmitIoLength Tab. A.24: Registry- Schlüssel für AfD – WinSock (Forts.)

Afd\Parameters for Windows Sockets Der Unterschlüssel Afd\Parameters speichert Werte für Afd.sys, einem »kernelmode«-Treiber, der TCP/IP-Anwendungen der Windows Sockets unterstützt.

BufferMultiplier REG_DWORD Multiplier Default: 512

Gibt einen Divisor vor; dieser wird verwendet, um zu berechnen wie viele Nachrichten gesendet bzw. empfanden werden können, bevor die Datenflusskontrolle tätig wird. Diese Zahl der Nachrichten wird wie folgt berechnet: Die Werte von »DefaultReceiveWindow« und »DefaultSendWindow« werden durch den Wert von »BufferMultiplier« geteilt. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

DefaultReceiveWindow REG_DWORD 0x0 – 0xFFFFFFFF Bytes Default: 0x2000 (8 KB)

Gibt die maximale Zahl der AFD-Empfangspuffer (Zahl in Bytes) an, jeweils für eine Verbindung, bevor die Datenflusskontrolle tätig wird. Applikationen können diesen Wert verändern; dies geschieht je Verbindung einzeln über die SocketOption »SO_RCVBUF«. Ein Anheben des Wertes »DefaultReceiveWindow« kann die Leistung etwas erhöhen, verbraucht aber mehr Ressourcen.

646

TCP/IP WinSock – AfD

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. Siehe auch: DefaultSendWindow

DefaultSendWindow REG_ DWORD 0x0 – 0xFFFFFFFF Bytes Default: 0x2000 (8 KB)

Gibt die maximale Zahl der AFD-Sendepuffer (Zahl in Bytes) an, jeweils für eine Verbindung, bevor die Datenflusskontrolle tätig wird. Applikationen können diesen Wert verändern; dies geschieht je Verbindung einzeln über die Socket-Option »SO_SNDBUF«. Ein Anheben des Wertes »DefaultReceiveWindow« kann die Leistung etwas erhöhen, verbraucht aber mehr Ressourcen. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. Siehe auch: DefaultReceiveWindow

DynamicBacklogGrowthDelta REG_DWORD 0x0 – 0xFFFFFFFF Default: 0x0

Legt die maximale Zahl verfügbarer Verbindungen fest, die eingerichtet werden, wenn das »dynamic backlog feature« ausgelöst wird. Wird »dynamic backlog« eingerichtet, muss der Parameter »DynamicBacklogGrowthDelta« in der Registry eingetragen werden mit einem Wert ungleich Null. Ist der Wert zu groß, kann es zu einem übermäßigen Anwachsen der Zahl freier Verbindungen kommen. Ein Wert von 10 (0x0A) wird empfohlen für Server, die unter flutartigen TCP-SYN-Anfragen leiden. (SYN=Synchronize Sequence Numbers, der Verbindungsaufbau bei TCP.) Dieser Eintrag wird erst unterstützt ab Windows NT 4.0 mit Service Pack 2 (oder später).

Anhang A • Die Registry von Windows NT

647

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

EnableDynamicBacklog REG_DWORD 0 | 1 Default: 0

Legt fest, ob das »dynamic backlog feature« eingeschaltet ist. Ist dies der Fall (Wert=1), arbeitet es im Zusammenhang mit den Werten für MinimumDynamicBacklog, MaximumDynamicBacklog und DynamicBacklogGrothDelta. Wert

Bedeutung

0

Dynamic Backlog ist auf AUS gestellt.

1

Dynamic Backlog ist auf EIN gestellt. Dies ist insbesonderen bei SYNStürmen empfohlen.

Tab. A.25: EnableDynamicBacklog

Dieser Eintrag wird erst unterstützt ab Windows NT 4.0 mit Service Pack 2 (oder später). Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

FastSendDatagramThreshold REG_DWORD 0x0 – 0xFFFFFFFF bytes Default: 0x400 (1 KB)

Gibt die maximale Größe der Datagramme an, die beim Senden an den Ausgangspuffer übergeben werden. Datagramme, deren Größe kleiner/gleich dem gegebenen Wert sind, werden beim Senden dem Ausgangspuffer übergeben. Größere Datagramme werden im Speicher gehalten, bis das Datagramm tatsächlich verwendet wurde. Der Vorgabewert (default) ist darauf ausgelegt, die bestmögliche Leistung zu erzielen. Jede Änderung könnte die Leistung des Rechners vermindern. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

648

TCP/IP WinSock – AfD

IgnorePushBitOnReceives REG_DWORD 0 | 1 Default: 0

Setzt fest, ob Afd.sys das TCP-Push-Bit (PSH) auswerten oder aber alle Pakete so behandeln soll, als ob das Push-Bit gesetzt wäre. Wert

Bedeutung

0

Windows NT führt einen Empfangsvorgang »receive()« des Windows Socket zu Ende beim Eingang von TCP-Daten, bei denen das Push-Bit (PSH) gesetzt ist, wenn der »user recv() buffer« voll ist oder wenn 0,5 Sekunden seit dem letzten Empfang beliebiger Daten vorüber sind.

1

Afd.sys liest das Push-Bit nicht aus. Es behandelt alle eingehenden Pakete so, als wäre das Push-Bit gesetzt.

Tab. A.26: IgnorePushBitOnReceives

Dieser Eintrag wird erst unterstützt ab Windows NT 3.51 mit Service Pack 5 (oder später). Dieser Wert sollte nicht verändert werden, solange es nicht notwendig ist, TCP/ IP-Implementationen nachzubessern, die Daten nicht korrekt »pushen« (Push: Weitergabe an die nächste Treiberinstanz bzw. an den nächsten Empfängerprozess). Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

InitialLargeBufferCount REG_DWORD

0x0 – 0xFFFFFFFF buffers

Default: (siehe Tabelle)

Default:

Speicher (RAM)

Vorgabewert

12,5 Mbyte oder weniger

0x0

12,5 Mbyte – 20 Mbyte

0x2

Mehr als 20 Mbyte

0xA (10)

Tab. A.27: InitialLargeBufferCount – Default Werte

Anhang A • Die Registry von Windows NT

649

Gibt an, wie viele »large buffers« (Puffer für große Pakete) AFD beim Systemstart belegt. Eine Erhöhung dieses Wertes kann die Leistung verbessern, verbraucht aber auch mehr Hauptspeicher. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

InitialMediumBufferCount REG_DWORD 0x0 – 0xFFFFFFFF buffers Default: (siehe Tabelle)

Default:

Speicher (RAM)

Vorgabewert

12,5 Mbyte oder weniger

0x2

12,5 Mbyte – 20 Mbyte

0xA (10)

Mehr als 20 Mbyte

0x1E (30)

Tab. A.28: InitialMediumBufferCount – Default Werte

Gibt an, wie viele »medium buffers« (Puffer für mittelgroße Pakete) AFD beim Systemstart belegt. Eine Erhöhung dieses Wertes kann die Leistung verbessern, verbraucht aber auch mehr Hauptspeicher. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

InitialSmallBufferCount REG_DWORD

0x0 – 0xFFFFFFFF Buffers

Default: (siehe Tabelle)

Default:

Speicher (RAM)

Vorgabewert

12,5 Mbyte oder weniger

0x5

12,5 Mbyte – 20 Mbyte

0x14 (20)

Mehr als 20 Mbyte

0x32 (50)

Tab. A.29: InitialSmallBufferCount – Default Werte

650

TCP/IP WinSock – AfD

Gibt an, wie viele »small buffers« (Puffer für kleine Pakete) AFD beim Systemstart belegt. Eine Erhöhung dieses Wertes kann die Leistung verbessern, verbraucht aber auch mehr Hauptspeicher. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

IrpStackSize REG_DWORD 0x0 – 0xFFFFFFFF stack locations Default: 0x4

Gibt die Zahl der »IRP stack locations« an, die für AFD belegt werden. Der Vorgabewert ist ausreichend um alle bestehenden Transportprotokolle zu bedienen, aber neue Transportprotokolle könnten erforderlich machen, dass mehr »IRP stack locations« eingerichtet werden müssen. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

LargeBufferSize REG_DWORD 0x0 – 0xFFFFFFFF Bytes Default: 0x1000 (4 Kbyte)

Gibt die Größe der »large buffers« an, die von AFD benutzt werden. Eine Erhöhung dieses Wertes kann die Leistung verbessern, verbraucht aber auch mehr Hauptspeicher. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

MaximumDynamicBacklog REG_DWORD 0x0-0xFFFFFFFF Connections Default: 0x0

Gibt die maximale Zahl der Verbindungen an, die zu einer Gegenstelle jeweils erlaubt sind, einschließlich freier Verbindungen sowie solcher Verbindungen, die

Anhang A • Die Registry von Windows NT

651

noch im Stadium des Aufbaus sind (half-connected, SYN_RECEIVED). Das »dynamic backlog feature« erhöht die Zahl der freien Verbindungen; anderenfalls würde der gegebene Wert von »MaximumDynamicBacklog« überschritten. Wenn »dynamic backlog« eingerichtet wird, muss der Wert »MaximumDynamicBacklog« in der Registry eingetragen und auf einen Wert ungleich 0x0 gesetzt werden. Richtlinie: Der Wert soll nicht mehr als 5.000 Verbindungen je 32 Mbytes (MN) physikalischen Hauptspeichers (RAM) beim Server betragen. Sollte dieser Wert zu hoch angesetzt sein, kann der »nonpaged memory pool« von auftretenden TCP-SYN-Stürmen verbraucht werden. Dieser Eintrag wird erst unterstützt ab Windows NT 4.0 mit Service Pack 2 (oder später). Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

MediumBufferSize REG_DWORD 0x0 – 0xFFFFFFFF Bytes Default: 0x5E0 (1.504 Bytes)

Gibt die Größe der »medium buffers« an, die von AFD benutzt werden. Eine Erhöhung dieses Wertes kann die Leistung verbessern, verbraucht aber auch mehr Hauptspeicher. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

MinimumDynamicBacklog REG_DWORD 0x0 – 0xFFFFFFFF Default: 0x0

Gibt die minimale Zahl freier Verbindungen an, die zu einer Gegenstelle jeweils erlaubt sind. Wenn die Zahl der freien Verbindungen unter diesen Wert fällt, wird das »dynamic backlog feature« ausgelöst, und zusätzliche freie Verbindungen werden erzeugt. Das »dynamic backlog feature« erhöht die Zahl der freien Verbindungen; anderenfalles würde der gegebene Wert von »MaximumDynamicBacklog« überschritten.

652

TCP/IP WinSock – AfD

Wenn »dynamic backlog« eingerichtet wird, muss der Wert »MaximumDynamicBacklog« in der Registry eingetragen und auf einen Wert ungleich 0x0 gesetzt werden. Richtlinie: Wird der Wert zu niedrig angesetzt, wird das »dynamic backlog« möglicherweise zu oft ausgelöst. Wird der Wert zu hoch angesetzt, kann das die Leistung vermindern, weil benötigte freie Verbindungen nicht verfügbar sind. Ein Wert von 20 wird empfohlen für Server, die unter TCP-SYN-Stürmen zu leiden haben. Dieser Eintrag wird erst unterstützt ab Windows NT 4.0 mit Service Pack 2 (oder später). Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

PriorityBoost REG_DWORD 0 – 16 (Priorität) Default: 2

Gibt den »priority boost« an, den AFD einem Vorgang (thread) gibt, wenn eine I/ O-Operation vollendet wird. Der Wert wird zur »base priority« des Vorgangs addiert, mit dem Ergebnis einer zeitweise erhöhten »thread priority«. AFD erhöht die Priorität (das ist der »boost«) eines Vorganges um die Wahrscheinlichkeit zu erhöhen, dass dieser vom Prozessor zur Verarbeitung herangezogen wird; diese höhere Wahrscheinlichkeit soll Verzögerungen ausgleichen, die bei der I/O-Operation auftreten. Wenn gelegentlich Vorgänge (threads) von »multithread applications« nicht ausreichend Prozessorzeit erhalten, kann eine Verminderung des Wertes für »PriorityBoost« erwogen werden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

SmallBufferSize REG_DWORD REG_DWORD 0x0 – 0xFFFFFFFF Bytes Default: 0x40 (64 Bytes)

Gibt die Größe der »small buffers« an, die von AFD benutzt werden. Eine Erhöhung dieses Wertes kann die Leistung verbessern, verbraucht aber auch mehr Hauptspeicher.

Anhang A • Die Registry von Windows NT

653

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

StandardAddressLength REG_DWORD 0x0 – 0xFFFFFFFF bytes Default: 0x18 (24 Bytes)

Setzt die Länge der TDI-Adressen fest, die typischerweise auf diesem Computer verwendet werden. Bei Verwendung von Transportprotokollen wie z.B. TP4, das sehr lange Adressen verwendet, kann eine Erhöhung des Wertes die Leistung in begrenztem Umfang verbessern. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

TransmitIoLength REG_DWORD 0x0 – 0xFFFFFFFF Bytes Default: (siehe Tabelle)

Default:

Operating system

TransmitIoLength

Windows NT Workstation

page size

Windows NT Server: klein

page size

Windows NT Server: mittel

page size x 2

Windows NT Server: groß

0x10000 (64 Kbyte)

Tab. A.30: TransmitIoLength – Default Werte

Setzt die Vorgabegröße für I/O-Vorgänge (Senden/Empfangen), die von der »TransmitFile()« API ausgeführt werden. Dieser Wert basiert auf der Größe der Speicherseiten (page size) – das ist die kleinste Einheit des physikalischen Hauptspeichers (RAM), die der Computer verwendet. Diese »page size« hängt von dem verwendeten Prozessor ab: Intel, MIPS und PowerPC verwenden eine Seitengröße von 4.096 Byte; DEC Alpha Prozessoren verwenden eine »page size« von 8.192 Bytes. Dieser Eintrag wird erst unterstützt ab Windows NT 3.51 mit Service Pack 5 (oder später).

654

AppleTalk-Adapterparameter

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

A.7

AppleTalk-Adapterparameter HKEY_LM\System\CurrentControlSet\Services\AppleTalk\Adapters\AdapterName AarpRetries DdpCheckSums DefaultZone NetworkRangeLowerEnd NetworkRangeUpperEnd PortName SeedingNetwork ZoneList Tab. A.31: Registry-Schlüssel für AppleTalk-Adapter

AarpRetries REG_DWORD 0x0 – 0xFFFFFFFF Default: 0xA (10)

Gibt die maximale Zahl der Pakete an, die AARP (AppleTalk Address Resolution Protocol) je Vorgang verwendet. Der Rechner muss neu gestartet werden, um den Einstellungen Wirkung zu verleihen.

DdpCheckSums REG_DWORD 0 | 1 Default: 0

Gibt an, ob AppleTalk die DDP-Prüfsumme rechnet (DDP=Datagram Delivery Protocol).

Anhang A • Die Registry von Windows NT

Wert

Bedeutung

0

Auf der Schicht von DDP werden die Prüfsummen nicht getestet.

1

Auf der Schicht von DDP werden die Prüfsummen getestet.

655

Tab. A.32: DhcpChecksums-Werte

Der Rechner muss neu gestartet werden, um den Einstellungen Wirkung zu verleihen.

DefaultZone REG_SZ Zone Name Default: (Es gibt keinen Vorgabewert für diesen Eintrag.)

Gibt die Vorgabezone des aktuellen Netzwerks an. Dieser Eintrag wird nur verwendet, wenn der Adapter das Netzwerk selber abfragt. Der Eintrag »DefaultZone« wird verändert, wenn in Systemsteuerung/Netzwerk unter »SFM« die Zone eingestellt wird. Um den Wert von »DefaultZone« zu verändern, sollte über Systemsteuerung/ Netzwerk gegangen werden. Der Rechner muss neu gestartet werden, um den Einstellungen Wirkung zu verleihen.

NetworkRangeLowerEnd REG_DWORD 1-65.279 Default: (Es gibt keinen Vorgabewert für diesen Eintrag.)

Dieser Wert entspricht der niedrigsten Netzwerknummer, die vom aktuellen Adressraum verwendet wird. Dieser Eintrag wird nur verwendet, wenn der Adapter das Netzwerk selber abfragt. Der Eintrag »DefaultZone« wird verändert, wenn in Systemsteuerung/Netzwerk unter »SFM« die Zone eingestellt wird. Um den Wert von »DefaultZone« zu verändern, sollte über Systemsteuerung/ Netzwerk gegangen werden. Der Rechner muss neu gestartet werden, um den Einstellungen Wirkung zu verleihen. Siehe auch: NetworkRangeUpperEnd

656

AppleTalk-Adapterparameter

NetworkRangeUpperEnd REG_DWORD 1-65.279 Default: (There is no default value for this entry.)

Dieser Wert entspricht der höchsten Netzwerknummer, die vom aktuellen Adressraum verwendet wird. Dieser Eintrag wird nur verwendet, wenn der Adapter das Netzwerk selber abfragt. Der Eintrag »DefaultZone« wird verändert, wenn in Systemsteuerung/Netzwerk unter »SFM« die Zone eingestellt wird. Um den Wert von »DefaultZone« zu verändern, sollte über Systemsteuerung/ Netzwerk gegangen werden. Der Rechner muss neu gestartet werden, um den Einstellungen Wirkung zu verleihen. Siehe auch: NetworkRangeLowerEnd

PortName REG_SZ AdapterName@ComputerName Default: (There is no default value for this entry.)

Dieser Wert nimmt den Namen auf, mit dem das AppleTalk-Protokoll identifiziert wird, das über einen bestimmten Adapter des Rechners arbeitet. Der Rechner muss neu gestartet werden, um den Einstellungen Wirkung zu verleihen.

SeedingNetwork REG_DWORD 0 | 1 Default: 0

Diese Einstellung entscheidet darüber, ob das AppleTalk-Protokoll selber das Netzwerk durchsucht (z.B., um die aktuelle Zone zu erkunden oder die Adresse). Diese Einstellung spielt beim Laden der AppleTalk-Protokolle eine Rolle. »Seed« bedeutet »aussäen, ausstreuen« von entsprechenden Abfragepaketen.

Anhang A • Die Registry von Windows NT

657

Wert

Bedeutung

0

Dieser Adapter fragt nicht selber das Netzwerk ab. (»This adapter does not seed the network.«) Das AppleTalk-Protokoll übergeht alle entsprechenden Nachrichten, die über das »Seeding« an ihn gerichtet werden.

1

Das AppleTalk-Protokoll fragt selber das Netzwerk ab (schickt Rundfragen ins Netzwerk) und empfängt seinerseits solche Pakete.

Tab. A.33: SeedingNetwork-Werte

Der Rechner muss neu gestartet werden, um den Einstellungen Wirkung zu verleihen.

ZoneList REG_MULTI_SZ List of Zones Default: (Es gibt keinen Vorgabewert für diesen Eintrag.)

Gibt die Zone an, in welcher das AppleTalk-Protokoll eigenständige Abfragen vornimmt (»Seeding«). Dieser Wert hat nur dann Auswirkungen, wenn der Adapter überhaupt mit »Seeding« arbeitet. Um den Wert von »DefaultZone« zu verändern, sollte über Systemsteuerung/ Netzwerk gegangen werden. Der Rechner muss neu gestartet werden, um den Einstellungen Wirkung zu verleihen.

A.8

Browser / Suchdienst HKEY_LM\System\CurrentControlSet\Services\Browser\Parameters BackupPeriodicity CacheHitLimit CacheResponseSize DirectHostBinding IsDomainMaster MaintainServerList MasterPeriodicity QueryDriverFrequency Tab. A.34: Registry-Schlüssel für Browser

Browser Service Entries

658

Browser / Suchdienst

BackupPeriodicity REG_DWORD 300-4.294.967 Sekunden Default: 720 Sekunden

Gibt an, wie oft ein »Backup Browser« seinen »Master Browser« kontaktiert. Dieser Wert wirkt sich nicht auf das WAN aus, weil dieser Datenverkehr immer nur auf einem Subnetz ist. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. Der Rechner muss neu gestartet werden, um den Einstellungen Wirkung zu verleihen. Siehe auch: MasterPeriodicity.

CacheHitLimit REG_DWORD 0-256 Default: 1

Setzt die Zahl der »NetServerEnum« fest, die benötigt wird, um sicher zu stellen, dass die Antwort auf eine »NetServerEnum«-Anfrage im Cache-Speicher ist. Wenn der Browser mehr »NetServerEnum«-Anfragen mit einem bestimmten Satz an Parametern erhält, als der Werte von »CacheHitLimit« vorgibt, werden die Antworten im Cache gespeichert und der Wert von »CacheHitLimit« an den Client zurüc gegeben. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

CacheResponseSize REG_DWORD 0x0-0xFFFFFFFF Default: 10

Gibt die maximale Zahl von Antworten an, die je Transportdienst (z.B. TCP) im Cache-Speicher gehalten werden. Ist der Wert von »CacheResponseSize« Null, werden die Antworten nicht im Cache gehalten.

Anhang A • Die Registry von Windows NT

659

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

DirectHostBinding REG_MULTI_SZ Service name Service name Default: \Device\NwlnkIpx \Device\NwlnkNb

Dieser Wert stellt die Verbindung her (»binding«) zwischen dem Browser-Dienst und dem »Direct Host IPX« (NwLnkIpx). Diese Bindung ist ein Zusatz zu den Bindungen der »LanmanWorkstation« (LAN Manager Workstation), die vom Windows NT Redirector für den Browser-Dienst erzeugt werden. Diese zusätzliche Bindung ist notwendig, weil die »LanmanWorkstation« nicht an »NwLnkIpx« gebunden werden kann. Der Vorgabewert \Device\NwlnkIpx \Device\NwlnkNb wird interpretiert wie folgt: »Wenn \Device\NwlnkNb an den Browser-Dienst gebunden ist, so binde auch \Device\NwLnkIpx an den Browser-Dienst.« Im Ergebnis bindet der Redirector den Browser-Dienst an NwLnkNb, und der Browser-Dienst erzeugt automatisch eine zusätzliche Bindung an NwLnkIpx.

IsDomainMaster REG_SZ TRUE | FALSE Default: FALSE

Gibt an, ob ein Arbeitsrechner (»workstation«) in der globalen LMHOSTS-Datei für TCP/IP enthalten ist. Wenn der Wert von »IsDomainMaster« auf TRUE gesetzt ist (der logische Ausdruck für WAHR=JA), wird die Priorität des Arbeitsrechners für den Browser erhöht, einschließlich einer verbesserten Leistung beim WAN-Browsing. Beispiel: Der Wert für »IsDomainMaster« wird in jeder Workgroup bei jeweils einigen Arbeitsrechnern auf TRUE gesetzt, und in in der globalen LMHOSTSDatei wird für jeden Arbeitsrechner ein Eintrag (»mapping«) erzeugt: In einer Gruppe von 20 Rechnern könnte der Wert von »IsDomainMaster« bei drei Rechnern auf TRUE gesetzt werden. Eine solche Einstellung würde die Wahrscheinlichkeit erhöhen, dass diese Rechner als »Master Browser« arbeiten einschließlich der Fähigkeit für »Remote Browsing« bei solchen Arbeitsrechnern, die in fernen Domänen angeschlossen sind und deren »Master Browser« Einträge (»mappings«) für diese drei besonderen Workgroup-Mitglieder enthält.

660

Browser / Suchdienst

MaintainServerList REG_SZ Yes | No | Auto Default: Auto

Der Wert dieses Eintrages gibt an, ob ein Server ein »Browse Server« ist. Wert

Bedeutung

Yes

Der Server wird zu einem »Browse Server«. Er wird versuchen, den »Master Browse Server« zu erreichen, um von diesem eine aktuelle »Browse List« zu beziehen. Kann kein »Master Browse Server« gefunden werden, erzwingt er ein Auswahlverfahren zum »Master Browse Server« (»election«) und wird selber Kandidat zum »Master Browser«. Der Rechner muss zum »Backup Browser« konfiguriert sein.

No

Der Server ist kein »Browse Server«.

Auto

Der Server fragt den »Master Browse Server« selbstständig darauf hin ab, ob er selber ein »Browse Server« werden soll.

Tab. A.35: MaintainServerList-Werte

MasterPeriodicity REG_DWORD 300-4.294.967 Sekunden Default: 720

Gibt vor, wie oft ein »Master Browser« den »Domain Master Browser« kontaktiert. Dieser Eintrag wird bei einem »Domain Master Browser« in die Registry gesetzt, um festzulegen, wie oft der »Domain Master Browser« die »Domain List« beim WINS abfragt (WINS=Windows Internet Name Service). Da jeder Rechner, der »Browser Server« ist, zum »Master Browser« erwählt werden kann, sollte dieser Eintrag bei jedem Windows-NT-Rechner innerhalb einer Domain vorhanden sein. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. Der Rechner muss nicht neu gestartet werden, um den Einstellungen Wirkung zu verleihen. Siehe auch: BackupPeriodicity

Anhang A • Die Registry von Windows NT

661

QueryDriverFrequency REG_DWORD 0-900 Sekunden Default: 30

Gibt vor, wie lange der »Master Browser« seinen »NetServerEnum«-AntwortCache pflegt. Wird der Wert dieses Eintrags überschritten, werden die Einträge vom »Master Browser« als ungültig angesehen. Der Wert »QueryDriverFrequence« gibt weiterhin vor, wie oft der »Master Browser« versucht, vom Browser-Treiber eine Liste aller Server zu erhalten. Eine Erhöhung des Wertes (Folge: das Abfragen der Server-Liste geschieht seltener) kann das »Browsing« etwas beschleunigen, aber die Server-List könnte im Einzelfall nicht aktuell sein. Eine Verminderung des Wertes (Folge: Das Abfragen der Server-Liste geschieht häufiger) macht es wahrscheinlicher, dass die ServerListe aktuell ist, verbraucht aber auch mehr Prozessorleistung für den »Master Browser«. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

A.9

DHCP-Client HKEY_LM\System\CurrentControlSet\Services\DHCP\Parameters\Options\ Option# KeyType RegLocation Tab. A.36: Registry-Schlüssel für DHCP Clients

DHCP Client Service Entries for TCP/IP Der Registry-Unterschlüssel »DHCP\Parameters« enthält seinerseits die Unterschlüssel »Option#« (Nummern: 02, 03, 04, ...); diese speichern Konfigurationsdaten, die der Client per DHCP-Abfrage durch Verwendung des DHCP-Managers erhalten kann. Diese Seite beschreibt die Werte »RegLocation« und »KeyType« der Einträge eines jeden »Option#«-Unterschlüssels. Tatsächlich stehen in der Registry statt »Option#« Zahlen – dies sind die Nummern der jeweiligen DHCP-Option. Die folgende Liste zeigt nicht alle Optionen, die im DHCP-Protokoll spezifiziert sind, da nicht alle für die Rückgabe durch den DHCP-Server gedacht bzw. geeignet sind oder sich einer sinnvollen Konfiguration entziehen.

662

DHCP-Client

Eine Liste aller DHCP-Optionen ist im Kapitel »Windows Networking« zu finden.

RegLocation REG_SZ Registry path Default: (Variiert mit der Option.)

Nennt den Registry-Eintrag, der die Daten zur Konfiguration der aktuellen Option enthält. Diese Daten werden vom DHCP-Server bezogen. Der Pfad zu dem Eintrag kann die Variable »?« enthalten; das Fragezeichen steht für den »Services«Unterschlüssel des jeweiligen Netzwerkadapters. Beispiel: Wenn der Wert von RegLocation der folgende Pfad ist, System\CurrentControlSet\Services\?\Parameters\Tcpip\DhcpSubnetMaskOpt so zeigt dieser Pfad an, dass die Daten für diese Option in dem Eintrag »DhcpSubnetMaskOpt« gespeichert sind, der wiederum in dem Pfad liegt HKEY_LM\ System\CurrentControlSet\Control\Services\AdapterName#\Parameters\Tcpip.

KeyType REG_DWORD 1 – 7 Default: (Variiert mit der Option.)

Gibt den Daten-Typ des Registryeintrags an, welcher die Konfigurationsdaten für den aktuellen Eintrag enthält. Der Wert des Eintrages ist über »RegLocation« definiert. Wert

Bedeutung

1 2 3 4 5 6 7

REG_SZ REG_EXPAND_SZ REG_BINARY REG_DWORDorREG_DWORD_LITTLE_ENDIAN REG_DWORD_BIG_ENDIAN REG_LINK REG_MULTI_SZ

Anhang A • Die Registry von Windows NT

663

Entry Values Diese DHCP-Optionen können von einem Win95/98/NT4-Client angenommen und verarbeitet werden. Alle weiteren DHCP-Optionen, die ein DHCP-Server zurückgeben würde, werden ignoriert. Option (hex.)

Option (dez.)

Länge in Bytes

Bedeutung

0x01

001

4

IP Subnet Mask

0x03

003

n

IP-Adresse(n): Router / Gateways

0x06

006

n

IP-Adresse(n): DNS Server

0x0F

015

n

Domain Name

0x2C

044

n

IP-Adresse(n): WINS-NBNS Server

0x2E

046

1

WINS-NBT Node Type (1,2,4,8)

0x2F

047

n

NetBIOS Scope ID (RFC 1001,1002)

0x33

051

4

IP Address Lease Time (Client/Server)

0x3A

058

4

Timer T1 / Renewal

0x3B

059

4

Timer T2 / Rebinding

Tab. A.37: DHCP-Client-Werte

A.10 DHCP Server HKEY_LM\System\CurrentControlSet\Services\DhcpServer\Parameters APIProtocolSupport BackupDatabasePath DatabaseCleanupInterval DatabaseLoggingFlag DatabaseName DatabasePath IgnoreBroadcastFlag RestoreFlag Tab. A.38: Registry-Schlüssel für DHCP-Server

DHCP Server Service Entries for TCP/IP Diese Einträge haben mit der grundsätzlichen Arbeitsweise des DHCP-Servers zu tun und sind nicht zu verwechseln mit den Einstellungen, die für die DHCPClients vorgenommen werden (können). Diese sind unter »Dhcp\Parameters\ Options\Option#« zu finden. Eine Liste aller Optionen des DHCP-Protokolls ist hier zu finden: DHCP Protocol Options.

664

DHCP Server

APIProtocolSupport REG_DWORD 1 | 2 | 4 | 5 | 7 Default: 5

Dieser Wert gibt für den DHCP-Server die unterstützten Protokolle an. Dieser Wert kann verändert werden, um sicherzustellen, dass verschiedene Computer mit verschiedenen Protokollen Zugriff auf den DHCP-Server erhalten. Wert

Bedeutung

1

Unterstützt TCP/IP.

2

Unterstützt »named pipes protocols«.

4

Unterstützt »local procedure call« (LPC) Protokolle.

5

Unterstützt TCP/IP and LPC.

7

Unterstützt alle drei Protokolle: TCP/IP, Named Pipes, LPC.

Tab. A.39: APIProtocolSupport-Werte

BackupDatabasePath REG_EXPAND_SZ Path Default: Systemroot\System32\Dhcp\Backup

Dieser Wert gibt den Ort jener Datei an, in der eine Sicherungskopie der Datenbank abgelegt ist. Siehe auch: BackupInterval RestoreFlag Speichern Sie die Sicherungsdatei auf einer anderen physikalischen lokalen Festplatte als der, auf welcher die Originaldatenbank liegt. Dies ist aus Gründen zuverlässiger Rückspeicherung im Fehlerfalle wichtig. Jedoch ist es nicht sinnvoll, die Sicherungsdatei auf einer via Netzwerk erreichbaren Festplatte eines anderen Rechners abzulegen, da der DHCP-Manager Netzwerklaufwerke nicht für das »Backup« und »Recovery« der DHCP-Datenbank verwenden kann.

BackupInterval REG_DWORD 0x0 – 0xFFFFFFFF Minuten Default: 0x3C (60 Minuten)

Anhang A • Die Registry von Windows NT

665

Dieser Wert gibt an, wie oft bzw. in welchen Abständen eine Sicherungskopie der DHCP-Datenbank erzeugt wird. Siehe auch: BackupDatabasePath RestoreFlag

DatabaseCleanupInterval REG_DWORD 0x0 – 0xFFFFFFFF Minuten Default: 0x3C (60 Minuten)

Dieser Wert gibt an, wie oft bzw. in welchen Abständen der DHCP-Server die Einträge jener DHCP-Clients aus der Datenbank löscht, deren Gültigkeitsdauer abgelaufen ist (»expired client records«). Das Löschen solcher durch Zeitüberschreitung ungültig gewordenen Einträge macht IP-Adressen frei zur Vergabe an andere Stationen.

DatabaseLoggingFlag REG_DWORD 0 | 1 Default: 1

Dieser Wert gibt an, ob Änderungen der DHCP-Datenbank in der Datei »jet.log« vermerkt werden (oder nicht). Die Datei »jet.log« wird nach einem Systemfehler verwendet, um Änderungen nachzutragen, die in der DHCP-Datenbank nicht (nicht mehr) vorhanden sind. Wert

Bedeutung

0

Änderungen in »jet.log« speichern = NEIN.

1

Änderungen in »jet.log« speichern = JA.

Tab. A.40: DatabaseLoggingFlag-Werte

Das Festhalten von Änderungen der DHCP-Datenbank in der Log-Datei »jet.log« kann die Gesamtleistung des Systems vermindern. Sollte dies der Fall sein, kann das Abschalten der Log-Funktion angemessen sein.

DatabaseName REG_SZ File Name Default: Dhcp.mdb

666

DHCP Server

Dieser Wert enthält den Namen der Datei, in welcher die DHCP-Client-Information als Datenbank hinterlegt ist.

DatabasePath REG_EXPAND Path Default: Systemroot\System32\Dhcp

Dieser Wert enthält den Pfad der DHCP-Datenbank-Dateien, die erzeugt und geöffnet wurden.

IgnoreBroadcastFlag REG_DWORD 0 | 1 Default: 1

Dieser Wert gibt an, ob das Broadcast-Bit (»broadcast flag«), das in DHCP-Rundrufen von Clients gesetzt sein kann, vom DHCP-Server beachtet oder übergangen werden soll. Die Vorgabeeinstellung ist, dass DHCP-Server, die auf WinNT 4.0 laufen, sämtlich DHCP-Antworten als IP-Broadcast an die Adresse 255.255.255.255 versenden (»limited broadcast address«). DHCP-Server können jedoch so eingestellt werden, die DHCP-Antwort statt per Broadcast via Unicast an den Client zurückzuschicken, sofern der der DHCP-Client in seiner Anfrage vermerkt, dass *keine* Broadcast-Rückantwort verlangt wird. Wert

Bedeutung

0

Der DHCP-Server wird sich gemäß dem »broadcast flag« verhalten, das der DHCP-Client setzte.

1

Der DHCP-Server wird das »broadcast flag« übergehen und sämtliche DHCP-Rückgaben per IP-Broadcast versenden.

Tab. A.41: IgnoreBroadcastFlag-Werte

Bei Microsoft-DHCP-Clients wird das Broadcast-Bit (»broadcast flag«) nicht gesetzt; das bedeutet, dass der DHCP-Client die Rückgaben des DHCP-Servers (DhcpOffer, DhcpAck) als Unicast-Pakete anfordert. Daher ist der Wert von »IgnoreBroadcastFlag« eher von Bedeutung gegenüber Non-Microsoft-Clients, die das Broadcast-Bit verwenden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

Anhang A • Die Registry von Windows NT

667

Der Rechner muss neu gestartet werden um den Einstellungen Wirkung zu verleihen. Wird »IgnoreBroadcastFlag« auf »0« gesetzt, so vermindert das den BroadcastVerkehr. Gleichwohl können Clients die Rückgabepakete »DhcpOffer« und »DhcpAck« nicht erhalten, wenn Microsoft DHCP-Server und -Client nicht im selben LAN-(Sub)-Segment angesiedelt sind. Bei LAN-Brücken (»bridges«), die »MAC Level Address Resolution« betreiben, kann die Verbindung zwischen DHCP-Server und -Client gefährdet sein; dies ist der Fall bei TokenRing-zuEthernet und FDDI-zu-Ethernet, da die MAC-Adressen bei Ethernet einerseits und TokenRing/FDDI andererseits auf Bit-Ebene in unterschiedlicher Reihenfolge interpretiert werden. Trennt ein Router die LAN-Segmente zwischen DHCP-Server und -Client, so kommt die Verbindung ggf. ebenfalls nicht zustande.

RestoreFlag REG_DWORD 0 | 1 Default: 0 Dieser Wert teilt dem Dienst des DHCP-Servers mit, dass die DHCP-Datenbank aus einem Verzeichnis mit Sicherungskopie zurückgesetzt werden muss. Der Wert dieses Eintrages wird selbsttätig auf »0« gesetzt, wenn dieser Vorgang der Rücksetzung erfolgreich durchgeführt wurde. Wert

Bedeutung

0

NEIN, keine Rücksetzung der Datenbank.

1

JA, Rücksetzung der Datenbank.

Tab. A.42: RestoreFlag-Werte

Siehe auch:

BackupDatabasePath BackupInterval DatabaseLoggingFlag

A.11 DLC-Adapterparameter HKEY_LM\System\CurrentControlSet\Services\DLC\Parameters\AdapterName Swap T1TickOne T1TickTwo T2TickOne

668

DLC-Adapterparameter

HKEY_LM\System\CurrentControlSet\Services\DLC\Parameters\AdapterName T2TickTwo TiTickOne TiTickTwo UseDixOverEthernet Tab. A.43: Registry-Schlüssel für DLC Adapter Parameter (Forts.)

DLC System Driver Entries Der Unterschlüssel »DLC« enthält Daten für den »Data Link Control« Protokolldienst. Der DLC-Unterschlüssel ist nicht von vornherein Teil der Registry; er taucht erst in der Registy auf, wenn DLC auf dem Rechner installiert wird. Der Unterschlüssel »Parameters« im Unterschlüssel »DLC« kann seinerseits einen oder mehrere Unterschlüssel enthalten, je einen für jeden LAN-Adapter, über den das DLC-Protokoll arbeitet. Die Werteeinträge in diesen LAN-Adapter-Unterschlüsseln sind nur für den jeweiligen LAN-Adapter gültig. Das DLC-Protokoll ist nur erforderlich bei Zugriff auf IBM-Großrechner (in der Regel mit 3.270-Anwendungen) oder auf Print-Server, die unmittelbar auf Drucker von Hewlett-Packard zugreifen. Netzwerkdrucker wie der »HP IIIsi« verwenden das DLC-Protokoll, weil die damit übertragenen Daten leicht in ihre Bestandteile zu zerlegen sind. Der DLC-Treiber verlangt nach einem »NDIS Group Service«. Der Grund liegt darin, dass der DLC-Treiber an den LAN-Adapter gebunden wird durch den NDIS-Geräte-Treiber. Hinweis Beim so genannten »DLC Protocol« handelt es sich schlicht um LLC-2 (Logical Link Control / Connection-Oriented Link Service = COLS). Warum ein mit IEEE 802.2 eindeutig beschriebenes Protokoll, nämlich LLC, unter dem anderen Namen »DLC / Data Link Control« verwendet bzw. eingeführt wurde, ist nicht klar. LLC CLLS = connectionsless link service LLC COLS = connection-oriented link service

Swap REG_DWORD 0 | 1 Default: 1

Anhang A • Die Registry von Windows NT

669

Dieser Wert gibt an, ob die Bits der Adapteradresse, wie sie an der Ebene der API-Schnittstelle dargestellt werden, von 0 auf 1 (oder von 1 auf 0) umgesetzt werden (oder nicht). Der Wert von »Swap« wird verwendet, wenn eine MACEmpfängeradresse über ein Token-Ring-LAN gesendet wird; hiermit werden bestimmte TokenRing-zu-Ethernet-Brücken unterstützt. Wert

Bedeutung

0

Die Adress-Bits werden nicht umgesetzt.

1

Die Adress-Bits werden umgesetzt entsprechend des IBM-Schemas für Ethernet-Geräte.

Tab. A.44: Swap-Werte

Hinweis Die obige Darstellung folgt der von Microsoft veröffentlichten Dokumentation. Es ist unsicher, ob diese Darstellung den Sachverhalt trifft. Der »Swap«Parameter könnte seinen Zweck darin haben, dass die MAC-Adressen bei Ethernet und Token-Ring zwar einheitlich mit dem LSB (Least Significant Bit) zuerst gesendet, aber intern unterschiedlich dargestellt werden: bei Token-Ring im MSB-Modus, bei Ethernet im LSB-Modus (MSB: Most Significant Bit; LSB: Least Significant Bit).

T1TickOne REG_DWORD 1-255 Millisekunden Default: 5

Dieser »TxTick«-Parameter wird verwendet, um die Verzögerung zu berechnen zwischen den Wiederholungen (ReTransmissions) von unbestätigten LLC Information Transfer (I)-Paketen (»delay between retransmissions of unacknowledged I-frames«).

T1TickTwo REG_DWORD 1-255 Millisekunden Default: 25

Dieser »TxTick«-Parameter wird verwendet, um die Verzögerung zu berechnen zwischen den Wiederholungen (ReTransmissions) von unbestätigten LLC Information Transfer (I)-Paketen (»delay between retransmissions of unacknowledged I-frames«).

670

DLC-Adapterparameter

T2TickOne REG_DWORD 1-255 Millisekunden Default: 1

Dieser »TxTick«-Parameter wird verwendet, um die Verzögerung zu berechnen, die Sie warten müssen, bevor der Erhalt von Paketen innerhalb des »Receive Window« bestätigt wird, sofern dieses »Receive Window« nicht voll ist. Der »Receive Buffer« bezeichnet den verfügbaren Eingangspuffer.

T2TickTwo REG_DWORD 1-255 Millisekunden Default: 10

Dieser »TxTick«-Parameter wird verwendet um, die Verzögerung zu berechnen, die Sie warten müssen, bevor der Erhalt von Paketen innerhalb des »Receive Window« bestätigt wird, sofern dieses »Receive Window« nicht voll ist. Der »Receive Buffer« bezeichnet den verfügbaren Eingangspuffer.

TiTickOne REG_DWORD 1-255 Millisekunden Default: 25

Dieser »TxTick«-Parameter wird verwendet um, die Verzögerung zu berechnen, die Sie warten müssen, bevor ein inaktiver LLC-Dialog-Partner daraufhin angetestet wird, ob er doch noch aktiv ist oder nicht.

TiTickTwo REG_DWORD 1-255 Millisekunden Default: 125

Dieser »TxTick«-Parameter wird verwendet, um die Verzögerung zu berechnen, die Sie warten müssen, bevor ein inaktiver LLC-Dialog-Partner daraufhin angetestet wird, ob er doch noch aktiv ist oder nicht.

Anhang A • Die Registry von Windows NT

671

UseDixOverEthernet REG_DWORD 0 | 1 Default: 0

Dieser Wert gibt an, welche Betriebsart per Voreinstellung für LLC-Dialoge über Ethernet gilt (verbindungslos oder verbindungsorientiert) hinsichtlich des Aufbaus der Ethernet-Frames. Wert

Bedeutung

0

Der DLC-Treiber verwendet das 802.3 Ethernet-Format zum Paket-Aufbau.

1

Der DLC-Treiber verwendet das DIX-Format zum Paket-Aufbau.

Tab. A.45: UseDixOverEthernet-Werte

Hinweis Dies zielt auf den Unterscheid zwischen dem älteren DIX-Standard (DIX=DEC-Intel-Xerox) und dem jüngeren IEEE-Standard 802.3. Das DIXStandard wird auch als »Ethernet II« oder »Blue Book Standard« bezeichnet.

A.12 DNS HKEY_LM\System\CurrentControlSet\Services\DNS\Parameters AddressAnswerLimit AutoCacheUpdate BindSecondaries CleanupInterval DisableAutoReverseZones DisjointNets EnableRegistryBoot Forwarders ForwardingTimeout IsSlave ListenAddresses NoRecursion RecursionRetry RecursionTimeout RpcProtocol WriteAuthorityNs WriteAuthoritySoa Tab. A.46: Registry-Schlüssel für DNS

672

DNS

DNS Parameters Subkey Entries Der Unterschlüssel DNS\Parameters enthält Werte für den DNS-Dienst (DNS=Domain Name Service). Siehe auch: DNS Zones Subkey Entries

AddressAnswerLimit REG_DWORD 0 | 5 – 28 Records Default: 0x0

Dieser Wert gibt die maximale Anzahl der »A«-Einträge an (= IP-Adressen), die der DNS-Server innerhalb eines einzelnen Antwortabschnittes (»answer section«) zurückgeben darf, wenn er auf eine Anfrage bezüglich eines A-Eintrages antwortet (wenn er also auf die Anfrage nach einer IP-Adresse antwortet). Der Wert dieses Eintrages wirkt sich auch auf das Setzen des »truncation bit« aus (siehe Tabelle unten). Wenn der Wert von »AddressAnswerLimit« zwischen 5 und 28 liegt, wird das »truncation bit« bei Antworten nicht gesetzt, selbst dann nicht, wenn der verfügbare Platz im Antwortpaket nicht ausreicht. Der Wert von »AddressAnswerLimit« hat nur Wirkung bei DNS-Anfragen auf AEinträge (»A record queries only«); andere Arten von DNS-Anfragen werden davon nicht berührt. Wert

Bedeutung

0

Es gibt keine Begrenzung der A-Einträge innerhalb einer DNS-Antwort. Sollten nicht alle A-Einträge in ein einziges Antwortpaket passen (UDPDNS), wird das »truncation bit« gesetzt; hierdurch wird angezeigt, dass die DNS-Antwort unvollständig, da sie sozusagen »abgeschnitten« ist.

5 – 28 Einträge

Der gegebene Wert gibt die maximal erlaubte Anzahl von A-Einträgen innerhalb einer DNS-Antwort an. Das »truncation bit« wird nicht gesetzt, und das ohne jede Rücksicht auf die tatsächliche Größe der DNS-Antwort.

Tab. A.47: AddressAnswerLimit-Werte

Der Parameter »AddressAnswerLimit« wurde eingeführt, um ein Problem zu lösen, das DNS bei Win95 hat (ohne Service Packs). Beim »rohen« Win95 schlagen DNS-Abfragen fehl, wenn auf eine Anfrage nach A-Einträgen mehr als 28 AEinträge zurückgegeben werden. Dieser Fehler tritt unregelmäßig auf und nur dann, wenn mehrere DNS-Server eine Website unterstützen. Aber auch unabhängig davon hat der Verzicht auf das Setzen des »truncation bit« den Vorteil, das ferne DNS-Server davon abgehalten werden, Wiederholungen via TCP einzuleiten. DNS-Server verwenden oftmals TCP zur Wiederholung von DNS-Anfragen, wenn sie eine DNS-Antwort erhalten, in der das »truncation bit« gesetzt ist.

Anhang A • Die Registry von Windows NT

673

Dieser Wert wird erst ab Windows NT 4.0 ab Service Pack 3 (oder später) unterstützt. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor, oder über sonstige Software, vorrangig den DNS-Manager.

AutoCacheUpdate REG_DWORD 0 | 1 Default: 1

Dieser Wert setzt fest, ob der Microsoft DNS Server versucht die Cache-Datei automatisch auf den neuesten Stand zu bringen, wenn er von einem »Root Server« erneuerte NS- und A-Anfragen für »Root Server« erhält. Wert

Bedeutung

0

NEIN: Der DNS-Server erneuert seine Cache-Datei nicht automatisch. Die Cache-Datei muss manuell auf den neuesten Stand gebracht werden durch den lokalen DNS-Administrator.

1

JA: Der DNS-Server versucht die Cache-Datei automatisch zu erneuern bzw. auf den aktuellen Stand zubringen.

Tab. A.48: AutoCacheUpdate-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software, vorrangig den DNS-Manager.

BindSecondaries REG_DWORD 0 | 1 Default: 1

Dieser Eintrag befähigt Microsoft DNS Server mit Non-Microsoft DNS Servern zusammenzuarbeiten, die ältere, langsame Versionen des DNS-BIND-Dienstes verwenden.

674

DNS

Wert

Bedeutung

0

Der Microsoft DNS Server legt möglichst viele Ressourcen-Einträge (»resource records«) in jede Nachricht, um ein Maximum an Kompression und Übertragungsgeschwindigkeit zu erreichen. Microsoft DNS Server sowie Non-Microsoft DNS Server, die BIND-Versionen ab 4.9.4 (oder höher) verwenden, können Übertragungen in diesem Format verarbeiten.

1

Der Microsoft DNS Server sendet Zonenübertragungen zu Non-Microsoft DNS Sekundär-Servern mit nur einem Ressourcen-Eintrag (»resource record«) je Nachricht. Non-Microsoft DNS Server, die ältere BIND-Versionen vor 4.9.4 verwenden, können nur Nachrichten verarbeiten, die in diesem Einzeleintrag-Betrieb verschickt werden.

Tab. A.49: BindSecondaries-Werte

Übertragungen zwischen Microsoft DNS Servern wenden immer die schnelle, mit Kompression arbeitende Methode an, unabhängig vom Wert des Eintrages BindSecondaries.

CleanupInterval REG_DWORD 0x0 – 0xFFFFFFFF Sekunden Default: 0xE10 (3600 Sekunden = 1 Stunde)

Dieser Wert gibt an, wie oft DNS eine routinemäßige Überprüfung der DNSDatenbank ausführt. Während des Prüfvorgangs entfernt DNS leere Einträge (»unreferenced records and notes«) und schreibt sämtliche Einträge auf die Festplatte, die aus administrativen Updates stammen und autorisierte Zonen (»authoritative zones«) betreffen. Weiterhin bereinigt dieser Prüfvorgang den von DNS verwendeten Speicher. Der Vorgabewert kann von den meisten DNS-Servern verwendet werden. Bei DNS-Servern, die unter einem Mangel an physikalischen Hauptspeicher leiden, kann eine Verminderung des Bereinigungsintervalls (also eine erhöhte Zahl an Bereinigungen) die Systemleistung verbessern. Wird das Intervall jedoch zu kurz angesetzt (weniger als 300 Sekunden), kann der Verbrauch an Prozessorzeit unverhältnismäßig ansteigen. Dieser Wert wird nur ab Windows NT 4.0 unterstützt. Der DNS-Manager von Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software, vorrangig den DNS-Manager.

Anhang A • Die Registry von Windows NT

675

DisableAutoReverseZones REG_DWORD 0 | 1 Default: 0

Dieser Wert gibt an, ob die DNS-Eigenschaft »Automatic Reverse Zones« verwendet wird (oder nicht). Diese Eigenschaft des DNS-Servers von WinNT 4.0 erlaubt drei »Reverse Lookup Zones« automatisch zu erzeugen. Wert

Bedeutung

0

EIN: Die Eigenschaft »Automatic Reverse Zones« wird verwendet. Der DNS-Server erzeugt drei »Reverse Lookup Zones« automatisch.

1

AUS: Die Eigenschaft »Automatic Reverse Zones« wird nicht verwendet. Der DNS-Server erzeugt keine »Reverse Lookup Zones« automatisch.

Tab. A.50: DisableAutoReverseZones-Werte

Die Eigenschaft »Reverse Lookup Zones« befähigt den DNS-Server, »authoritativ« zu sein, was bedeutet, dass er bei DNS-Anfragen auf Namensauflösung die Antwort meistens schon im Voraus kennt und unverzüglich antworten kann, wodurch unnötige rekursive Anfragen vermieden werden. Im Einklang mit den entsprechenden RFCs ist der DNS-Server »authoritativ« für drei »Reverse Lookup Zones«: 0.

in-addr.arpa.

(0.0.0.0)

127.

in-addr.arpa.

(127.0.0.1 – loopback)

255.

in-addr.arpa.

(255. 255. 255. 255 – broadcast)

Tab. A.51: DNS-Zonen / Reverse Lookup Zones

Die Verwendung von »Automatic Reverse Zones« verbessert die Leistung des DNS-Servers. Der Vorgabewert ist für die überwiegend meisten DNS-Server geeignet. Dieser Wert nur ab Windows NT 4.0 unterstützt. Der DNS-Manager von Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software, vorrangig den DNS-Manager.

676

DNS

DisjointNets REG_DWORD 0 | 1 Default: 0 (See variation for Service Pack 3)

Dieser Wert bewirkt, dass das vorgegebene DNS-Verhalten beim Binden von Sokkets an IP-Adressen übergangen wird. Wird »DisjointNets« auf »1« gesetzt, so wird der DNS-Server gezwungen ungebundene Sockets zu verwenden, wenn Anfragen an andere DNS-Server zu versenden sind. Dieser Werteeintrag wird nur bei DNS-Servern verwendet, die auf »Multi-Homed«-Maschinen laufen und somit an mehrere getrennte Netzwerke angeschlossen sind (»connected to multiple disjoint networks«). Wird »DisjointNets« auf »1« gesetzt, so hilft dies, sicherzustellen, dass der DNSServer die korrekte Bindung für die Socket-Schnittstelle wählt. Wert

Bedeutung

0

Das vorgegebene Verhalten des DNS-Servers wird nicht verändert. Der DNS-Server sucht einen Socket, der entweder an die erste IP-Adresse gebunden ist, die sich in der IP-AdressListe des DNS-Servers befindet, oder der an die erste IP-Schnittstelle gebunden ist, die auf dem Rechner konfiguriert ist. Wenn der auswärtige DNS-Server zu der gewählten IP-Adresse nicht antworten kann, weil er an zwei oder mehr Netzwerke angeschlossen ist, die untereinander nicht vollständig verbunden sind, schlagen rekursive DNSAuflösungen fehl.

1

Das vorgegebene Verhalten des DNS-Servers wird übergangen. Der DNS-Server sendet Anfragen (Queries) über einen ungebundenen Socket. Dies setzt TCP/IP in die Lage, genau die IP-Absendeadresse auszuwählen, die für den Netzwerkadapter gilt, über den Anfragen an auswärtige DNS-Server geschickt werden.

Tab. A.52: DisjointNets-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software, vorrangig den DNS-Manager. Wenn dieser Eintrag mit dem Wert »1« in die Registry eingefügt wird, muss ebenfalls die IP-Adress-Liste des DNS-Servers geleert werden. Danach »hört« der DNS-Server an allen IP-Schnittstellen auf Antworten auswärtiger DNS-Server. Bei Windows NT 4.0 mit Service Pack 3 (oder später) gilt für »multi homed« DNSServer, die an mehrere Netzwerke angeschlossen sind und auf allen IP-Schnittstellen DNS betreiben, dass sie DNS-Anfragen über ungebundene Sockets senden.

Anhang A • Die Registry von Windows NT

677

Anderenfalls sendet der DNS-Server seine Anfragen über Sockets, die auf die erste (und/oder einzige) IP-Adresse gebunden sind. Der Eintrag »DisjointNets« sollte nicht in die Registry eingetragen werden, solange der DNS-Server nicht in einer Umgebung unverbundener/getrennter Subnetze betrieben (»disjointed topology«) wird und Probleme beim Kontakt zu anderen DNS-Servern auftauchen.

EnableRegistryBoot REG_DWORD 0 | 1 Default:: (siehe unten)

Dieser Eintrag gibt an, wo die Quelldaten beim Start des DNS-Servers zu suchen sind. Wert

Bedeutung

0

Der DNS-Server verwendet beim Starten eine Boot-Datei im Verzeichnis Systemroot\System32\Dns.

1

Der DNS-Server verwendet beim Start Werte, die in der Registry hinterlegt sind.

Tab. A.53: EnableRegistryBoot-Werte

Bei der Installation von DNS verwendet der DNS-Server beim Start die Werte der Boot-Datei – so, als wäre der Wert von »EnableRegistryBoot« auf »0« gesetzt. Wie dem aber auch sei: Nachdem der DNS-Manager das erste Mal dazu verwendet wurde, um einen Wert zu verändern, der die Boot-Datei betrifft, hört der DNSServer auf, diese zu verwenden, und hinterlegt die Einstellungen in der Registry. Danach startet das System mit den Registry-Werten. Zu dieser Zeit legt der DNSServer den Eintrag »EnableRegistryBoot« in der Registry an und setzt den Wert auf »1«; die nun nicht mehr verwendete Boot-Datei wird in ein Sicherungsverzeichnis unterhalb von Systemroot\System32\Dns verschoben. Die Änderung in der Quelle der Startdaten wird ausgelöst durch die Verwendung des DNS-Managers zur Anlage oder Löschung einer Zone, zur Änderung der Sendeeinstellungen, oder zur Anlage einer Zoneneigenschaft, die von der BootDatei nicht unterstützt wird, etwa »Secure Secondaries« oder »Notify List«. Wird der Wert von »EnableRegistryBoot« auf »0« gesetzt, geht sämtliche Information verloren, die in der Registry hinterlegt wurde, einschließlich der Zoneninformation, sofern diese nicht in »Zone Files« gespeichert wurde. Der Eintrag »EnableRegistryBoot« wird bei Installation von DNS nicht erzeugt. Bei Windows NT Server, Service Pack 3 (oder früher), legt der DNS-Server »EnableRegistryBoot« nur dann in der Registry an, wenn der Wert auf »1« gesetzt wird.

678

DNS

Forwarders REG_BINARY Durchgezählte Reihe roher IP-Adressen in Net-ByteReihenfolge Default: (Vorgabe: Kein Registry-Eintrag; das System geht hierbei von einem Leerfeld ohne Forwarder aus.)

Dieser Eintrag listet diejenigen DNS-Server auf, zu denen der lokale DNS-Server sämtliche Rekursiv-Anfragen, auswärtige Namen betreffend, sendet. Die in dieser Liste enthaltenen DNS-Server werden als »Forwarder« bezeichnet. Die DNS-»Forwarder«-Server stellen ihrerseits Verbindung zu weiteren DNSServern her und leiten deren Antworten in einer Form weiter, die geeignet ist, an den Client gesendet zu werden. Sind keine Adressen im Wertefeld von »Forwarders« gegebenen, oder ist »Forwarders« nicht in der Registry vorhanden, verwendet der DNS-Server keine DNS-»Forwarder«-Server. Stattdessen verwendet DNS eine übliche, schrittweise Abfrageprozedur, um Rekursiv-Anfragen auf auswärtige Namen zu beantworten. »Forwarders« vermindern den Abfrageverkehr auf langsamen Strecken, etwa Wählleitungen ins Internet. Wenn der DNS-»Forwarder«-Server beim Internetdienstleister steht bzw. von diesem gestellt wird, reicht ein einziger, kurzer DNSDialog aus, um eine Anfrage aufzulösen. Der verbleibende Verkehr wird vom DNS-»Forwarder«-Server auf der anderen Seite übernommen. DNS-»Forwarder«-Server können auch verwendet werden, um den Abfrageverkehr mehrer DNS-Server auf einem LAN zu zentralisieren. Wenn alle DNS-Server ihre Anfragen zum selben DNS-»Forwarder«-Server leiten, werden alle Ergebnisse aller Anfragen im Cache des »Forwarder«-Servers gespeichert – mit der Folge, dass die Wahrscheinlichkeit steigt, dass Anfragen aus diesem Cache heraus beantwortet werden können und somit weitere Aktivitäten entfallen. Weiterhin hat die Zentralisierung Sicherheitsvorzüge, da nur dieser eine DNS-Server gegenüber offenen, unsicheren Netzen geschützt werden muss. Dieser Wert nur ab Windows NT 4.0 unterstützt. Der DNS-Manager von Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software, vorrangig den DNS-Manager. Es ist nicht möglich, IP-Adressen in der Dezimalform »dotted decimal« zu schreiben. Um die Einträge von »Forwarders« zu ändern, sollte die entsprechende Tabelle im DNS-Manager verwendet werden; dort tauchen die IP-Adressen in der gewohnten Form »dotted decimal« auf. Im Hintergrund werden dann die IPAdressen konvertiert, wenn sie in die Registry geschrieben werden.

Anhang A • Die Registry von Windows NT

679

Allgemein ist ein einzelner DNS-»Forwarder«-Server wirkungsvoller als mehrere, da sich die Einträge in dem Cache einer einzigen Maschine sammeln (s.o.). Um zu erreichen, dass ein »Forwarder«-Server mehr als ein Mal angefragt wird, wenn die erste Abfrage fehlschlug, sollte die IP-Adresse des »Forwarder«-Servers mehr als nur ein Mal in der Forwarder-Tabelle eingetragen sein.

ForwardingTimeout REG_DWORD 0x0 – 0xFFFFFFFF Sekunden Default: 0x5

Dieser Wert gibt an, wie lange DNS auf die Antworten der Forwarder-Server wartet, nachdem eine Anfrage an sie gerichtet wurde. Wenn ein Forwarder-Server nicht innerhalb des Zeitlimits antwortet (also Eintritt einer Zeitüberschreitung), schickt DNS die Anfrage an den nächsten Forwarder-Server, der in der Forwarder-Liste eingetragen ist. Antwortet keiner der Forwarder-Server innerhalb der mit »ForwardingTimeout« gesetzten Frist, hängt es vom Wert »IsSlave« ab, wie der DNS-Server auf die ursprüngliche Anfrage antwortet. Der Wert von »ForwardingTimeout« hat nur Auswirkung, wenn im Wertebereich von »Forwarders« mindestens eine gültige IP-Adresse eingetragen ist. Dieser Wert wird nur bei Windows NT 4.0 unterstützt. Der DNS-Manager von Windows NT nimmt diesen Eintrag nicht selber vor; erst bei entsprechenden Änderungen über den DNS-Manger ist dies der Fall. Für Änderungen von »ForwardingTimeout« sollte im DNS-Manger die Forwarder-Tabelle verwendet werden. Bei falschem Eintrag oder bei Löschung dieses Eintrages kann es zu Fehlern im Betrieb des DNS-Servers kommen. Siehe auch: RecursionRetry RecursionTimeout

IsSlave REG_DWORD 0 | 1 Default: 0

Dieser Wert gibt an, wie der DNS-Server antwortet, wenn er keine Antwort auf eine eigene Anfrage erhält. Dieser Eintrag hat nur dann Wirkung, wenn der Wert von »Forwarders« mindestens eine gültige IP-Adresse enthält.

680

DNS

Wert

Bedeutung

0

Der DNS-Server ist nicht auf »Slave« eingestellt. Wenn der/die Forwarder-Server nicht antwortet, versendet der DNS-Server übliche Schritt-für-Schritt-Anfragen um den fraglichen Namen aufzulösen.

1

Der DNS-Server ist auf »Slave« eingestellt. Wenn der/die Forwarder-Server nicht antworten, beendet der DNS-Server die Suche und sendet als Antwort auf die ursprüngliche Anfrage die Meldung SERVER_FAILURE.

Tab. A.54: IsSlave-Werte

Dieser Wert wird nur bei Windows NT 4.0 unterstützt. Der DNS-Manager von Windows NT nimmt diesen Eintrag nicht selber vor. Der Eintrag wird bei entsprechender Verwendung des DNS-Mangers durch den Benutzer erzeugt. Für Änderungen von »ForwardingTimeout« sollte im DNS-Manger die Forwarder-Tabelle verwendet werden. Bei falschem Eintrag oder bei Löschung dieses Eintrages kann es zu Fehlern im Betrieb des DNS-Servers kommen.

ListenAddresses REG_BINARY Durchgezählte Reihe roher IP-Adressen in Net-ByteReihenfolge Default: (Vorgabe: Kein Registry-Eintrag; das System geht hierbei von einem Leerfeld ohne ListenAddress aus. Der DNS-Server versucht alle IP-Adressen auf den Rechner zu binden.)

Dieser Wert listet die IP-Adressen auf, die an den DNS-Server gebunden wurden. Sind keine Adressen im Wertefeld von »ListenAddresses« aufgeführt oder taucht der Eintrag von »ListenAddresses« in der Registry nicht auf, so versucht der DNS-Server, alle IP-Adressen auf den Rechner zu binden. Der Vorgabewert ist für die meisten DNS-Server hinreichend geeignet. Jedoch kann es angeraten sein, bestimmte Schnittstellen auszuschließen, besonders dann, wenn Windows NT 4.0 Service Pack 1 (oder früher) betrieben wird, weil diese alten Versionen nicht mehr als 15 IP-Adressen binden können. Weiterhin ist der DNS-Server nicht in der Lage, mehr als 35 Schnittstellen einwandfrei zu erkennen und zu binden. Dieser Wert wird nur ab Windows NT 4.0 unterstützt. Der DNS-Manager von Windows NT nimmt diesen Eintrag nicht selber vor; erst bei entsprechenden Änderungen über den DNS-Manger ist dies der Fall.

Anhang A • Die Registry von Windows NT

681

Es ist nicht möglich, IP-Adressen in der Dezimalform »dotted decimal« zu schreiben. Um die Einträge von »Forwarders« zu ändern, sollte die SchnittstellenTabelle im DNS-Manager verwendet werden; dort tauchen die IP-Adressen in der gewohnten Form »dotted decimal« auf. Im Hintergrund werden dann die IPAdressen konvertiert, wenn sie in die Registry geschrieben werden.

NoRecursion REG_DWORD 0 | 1 Default: 0

Dieser Wert gibt an, ob der DNS-Server rekursive Auflösungen durchführt. Rekursive Auflösungen erfordern, dass der DNS-Server jegliche Client-Anfrage auf Namensauflösung an andere DNS-Server weiterreicht, sofern der abgefragte Name (noch) nicht in seiner »authoritative zone« enthalten und (noch) keine entsprechende, authoritative Antwort (»authoritative response«) anderer DNS-Server eingegangen ist. Erhält der DNS-Server eine authoritative Antwort, so leitet er die Antwort an den DNS-Client weiter. Namens-Server sollten so eingestellt sein, dass sie rekursive Auslösung unterstützen. Es kann aber auch Gründe geben, sich gegen die rekursive Auflösung zu entscheiden, beispielsweise bei einem Intranet-DNS-Server, der keine Verbindung ins Internet hat (was nicht empfohlen wird), oder bei einem Intranet-DNS-Server, der zwar ans Internet geschlossen ist, aber keine lokalen DNS-Clients unterstützt. Wert

Bedeutung

0

Der Microsoft DNS Server führt rekursive Auflösungen durch entsprechend dem Anfragetyp des DNS-Clients. Wenn das »RecursionDesired«-Bit im Header der DNS-Namensanfrage gesetzt ist, wird die rekursive Auslösung seitens des DNS-Servers durchgeführt. Ist das »RecursionDesired«-Bit nicht gesetzt, führt der DNS-Server die rekursive Auflösung nicht durch und sendet lediglich den Verweis auf einen anderen DNS-Server an den DNSClient. Dieser Verweis enthält den NS- und A-Eintrag für den anderen DNS-Server.

1 (oder jeder andere Wert ungleich Null)

Der Microsoft DNS-Server führt keine rekursiven Auslösungen durch. Wenn der DNS-Server eine Anfrage auf Auflösung eines Namens erhält, der außerhalb seiner »authoritative zone« liegt und dessen Wert auf »1« gesetzt ist, so sendet der DNS-Server dem DNS-Client einen Verweis auf einen anderen DNS-Server, über den die Auflösung erreicht werden kann.

Tab. A.55: NoRecursion-Werte

682

DNS

Dieser Wert wird nur ab Windows NT 4.0 (oder später) unterstützt. Der DNS-Manager von Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software, vorrangig den DNS-Manager.

RecursionRetry REG_DWORD 0x1 – 0xFFFFFFFF Sekunden Default: 0x3

Dieser Wert gibt an, wie oft der DNS-Dienst rekursive Client-Anfragen wiederholt, wenn keine Antworten von anderen DNS-Servern eingehen. Erhält der DNS-Server keine Antworten anderer DNS-Server innerhalb der dafür mit »RecursionRetry« gesetzten Zeitbegrenzung, so wiederholt er die Anfrage – sei es demselben DNS-Server gegenüber, sei es anderen gegenüber. Der Vorgabewert ist für die meisten DNS-Server hinreichend geeignet. Es kann jedoch der Fall sein, dass die gesetzte Zeit geringer ist als die Antwortzeit eines auswärtigen DNS-Servers, der über eine langsame Verbindung erreicht wird; in diesem Falle sollte die Wartezeit, die in »RecursionRetry« hinterlegt ist, etwas länger sein als die Antwortzeit des betroffenen auswärtigen DNS-Servers. Dieser Wert wird nur bei Windows NT 4.0 unterstützt (oder später). Der DNS-Manager von Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software, vorrangig den DNS-Manager. Siehe auch: ForwardingTimeout RecursionTimeout

RecursionTimeout REG_DWORD 0x1 – 0xFFFFFFFF Sekunden Default: 0xF (15 Sekunden)

Dieser Wert gibt an, wie lange der DNS-Dienst bei rekursiven Client-Anfragen wartet, bis Antworten von anderen DNS-Servern eingehen (oder eben nicht). Erhält der DNS-Server keine Antworten anderer DNS-Server innerhalb der dafür mit »RecursionRetry« gesetzten Zeitbegrenzung, so wiederholt er die Anfrage – sei es demselben DNS-Server gegenüber, sei es anderen gegenüber.

Anhang A • Die Registry von Windows NT

683

Haben aber auch Wiederholungen der Anfragen gegenüber anderen DNS-Servern zu keiner Antwort bzw. Auflösung innerhalb der durch »RecursionTimeout« gesetzten Wartezeit geführt, so wird die Suche beendet und es wird eine SERVER_FAILURE Meldung an den Client zurückgesendet. Der Vorgabewert ist für die meisten DNS-Server hinreichend geeignet. Es kann jedoch der Fall sein, dass die gesetzte Zeit geringer ist als die Antwortzeit eines auswärtigen DNS-Servers, der über eine langsame Verbindung erreicht wird; in diesem Falle sollte die Wartezeit, die in »RecursionRetry« hinterlegt ist, etwas länger sein als die Antwortzeit des betroffenen auswärtigen DNS-Servers. Es sollte die Unterscheidung der Wartezeiten »RecursionRetry« und »RecursionTimeout« berücksichtigt werden. Gleiches gilt für die Unterscheidung der Antwortzeit des fernen DNS-Servers einerseits und der wiederholten Auflösungsanfragen bzw. Anfrageversuchen des Clients andererseits. Dieser Wert wird nur bei Windows NT 4.0 unterstützt. Der DNS-Manager von Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software, vorrangig den DNS-Manager. Siehe auch:

ForwardingTimeout

RpcProtocol REG_DWORD 0x0 – 0x8 | 0xFFFFFFFF Default: 0xFFFFFFFF

Dieser Wert gibt die Protokolle an, über die administrative RPC-Pakete laufen. RPC = Remote Procedure Call LPC = Local Procedure Call Wert (hex)

Wert (binär)

0x0

Bedeutung Keine Protokolle. (Diese Einstellung muss nicht unbedingt RPC-fürDNS ausschließen; siehe Hinweis unten.)

0x1

001

TCP/IP

0x2

010

Named Pipes

0x3

011

TCP/IP und Named Pipes

0x4

100

LPC

0x5

101

LPC und TCP/IP

Tab. A.56: RpcProtocol-Werte

684

DNS

Wert (hex)

Wert (binär)

Bedeutung

0x6

110

LPC und Named Pipes

0x7

111

TCP/IP, LPC, Named Pipes

0x8

Kein RPC.

0xFFFFFFFF

All verfügbaren Protokolle.

Tab. A.56: RpcProtocol-Werte (Forts.)

Um das RPC-Protokoll von allen Diensten des Rechners auszuschließen bzw. abzuschalten, sind die Werte »RpcSS« und »NtLmSsp« im Eintrag von »DependOnService« in folgendem Unterschlüssel zu löschen: HKEY_LM\System\CurrentControlSet\Services\DNS Um das RPC-Protokoll nur für DNS auszuschalten, wird der Wert von »RpcProtocol« auf »0x8« gesetzt. Wird der Wert auf »0x0« gesetzt, oder wird »RpcProtocol« aus der Registry entfernt, wird der DNS-Dienst den Eintrag »RpcProtocol« in der Registry wieder einrichten und RPC erneut einschalten. Dieser Wert wird nur ab Windows NT 4.0 unterstützt.

WriteAuthorityNs REG_DWORD 0 | 1 Default: 0

Dieser Wert gibt an, wann der DNS-Server NS-Einträge im Abschnitt »Authority« einer DNS-Antwort zurückgeben wird. Zweck des Parameters »WriteAuthorityNS« ist es, den BIND-Dienst davon abzuhalten, unnötige NS-Einträge im »Authority«-Abschnitt aufzuführen; auch soll sichergestellt werden, dass sich der DNS-Server entsprechend den einschlägigen RFCs verhält. Wert

Bedeutung

0

Der DNS-Server schreibt NS-Einträge in den »Authority«-Abschnitt nur bei Verweisen. Dieses Vorgehen entspricht RFC-1034 und dem DNSIND Clarity Draft.

1

Der DNS-Server schreibt NS-Einträge in den »Authority«-Abschnitt bei allen erfolgreichen »authoritativen« Antworten. Einige dieser NS-Einträge sind weder erforderlich, noch hilfreich.

Tab. A.57: WriteAuthorityNs-Werte

Anhang A • Die Registry von Windows NT

685

Der Vorgabewert ist für die meisten DNS-Server hinreichend geeignet. Die Ausgabe von NS-Einträgen im »Authority«-Abschnitt verbraucht Prozessorzeit und Netzwerkdurchsatz; es wird davon abgeraten, sofern nicht die Netzwerkapplikation oder der Netzwerkdienst sie erfordern. Dieser Wert wird nur ab Windows NT 4.0 unterstützt ab Service Pack (oder später). Der DNS-Manager von Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. Siehe auch:

WriteAuthoritySoa

WriteAuthoritySoa REG_DWORD 0 | 1 Default: 0

Dieser Wert gibt an, wann der DNS-Server SOA-Einträge in dem Abschnitt »Authority« einer DNS-Antwort zurückgeben wird. Zweck des Parameters »WriteAuthoritySoa« ist es, den BIND-Dienst davon abzuhalten, unnötige SOA-Einträge im »Authority«-Abschnitt aufzuführen; auch soll sichergestellt werden, dass sich der DNS-Server entsprechend den einschlägigen RFCs verhält. Wert

Bedeutung

0

Der DNS-Server schreibt SOA-Einträge im »Authority«-Abschnitt nur bei Negativ-Antworten (NAME_ERROR). Die Negativ-Antwort kann vom DNS-Server im Cache gespeichert werden. Diese Vorgehensweise entspricht RFC-1034 und dem DNSIND Clarify Draft.

1

Der DNS-Server schreibt SOA-Einträge im »Authority«-Abschnitt bei allen erfolgreichen Antworten. Einige dieser SOA-Einträge sind weder erforderlich noch hilfreich.

Tab. A.58: WriteAuthoritySoa-Werte

Der Vorgabewert ist für die meisten DNS-Server hinreichend geeignet. SOA-Einträge im »Authority«-Abschnitt auszugeben, verbraucht Prozessorzeit und Netzwerkdurchsatz; es wird davon abgeraten, sofern nicht die Netzwerkapplikation oder der Netzwerkdienst sie erfordern. Dieser Wert wird nur ab Windows NT 4.0 ab Service Pack 3 (oder später) unterstützt.

686

DNS Zones

Der DNS-Manager von Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. Siehe auch: WriteAuthorityNs

A.13 DNS Zones HKEY_LM\System\CurrentControlSet\Services\DNS\Zones\Zone name DatabaseFile MasterServers SecondaryServers SecureSecondaries Type UseDatabase Tab. A.59: Registry-Schlüssel für DNS Zones

DNS Zones Subkey Entries Bei Windows NT 4.0 (oder später) enthält der Registry-Unterschlüssel des DNSDienstes einen »Zones«-Unterschlüssel, der Informationen über die »authoritative zones« des DNS-Servers enthält. Weiterhin enthält der »Zones«-Unterschlüssel seinerseits Unterschlüssel, die jeweils einer der »authoritative zones« am DNSServer entsprechen; Konfigurationsdaten werden für jede »authoritative zone« getrennt gespeichert. Ist der DNS-Server nicht hauptsächlich zuständig für eine Zone (»not root authoritative«), enthält der »Zones«-Unterschlüssel einen weiteren Unterschlüssel mit dem Namen ».« (Punkt); dieser enthält Konfigurationsdaten der Cache-Datei (auch bekannt als »root hint file«). Die Werteinträge dieses Unterschlüssels werden benötigt, wenn DNS mit Werten aus der Registry bootet. Um die Quelldaten beim DNS-Boot festzulegen, ist der Eintrag »EnableRegistryBoot« zu bearbeiten. Wird der Wert von »EnableRegistryBoot« auf »0« gesetzt, werden der Unterschlüssel »Zones« und sein sämtlicher Inhalt gelöscht.

DatabaseFile REG_SZ Datei-Name Default: (Einen Vorgabewert für diesen Eintrag gibt es nicht.)

Dieser Wert gibt den Namen der Datenbankdatei der Zone an. Er bestimmt die Datei, die beim Starten des DNS-Dienstes zur Einrichtung der Zone gelesen wird (sofern mit Werten aus der Registry gestartet wird, siehe »EnableRegistryBoot«).

Anhang A • Die Registry von Windows NT

687

Wird der DNS-Dienst gestartet mit Werten aus der Bootdatei, wird der dort angegebene Name der Datenbankdatei in diesem Eintrag »DatabaseFile« gespeichert; ein ggf. vorhandener früherer Wert von »DatabaseFile« wird überschrieben. Der Wert dieses Eintrags (also der Name der Datenbankdatei) ist erforderlich für Primärzonen (»primary zones«); für Sekundärzonen ist der Wert nur notwendig, wenn diese aus Zonendateien eingeladen werden. Dieser Wert wird erst ab Windows NT 4.0 (oder später) unterstützt. Dieser Wert sollte nicht verändert werden. Um eine andere Zone anzugeben (oder gar keine Zonendatei), sollte die »General«-Tabelle der »Zone Properties« (Zoneneigenschaften) im DNS-Manager verwendet werden. Siehe auch: EnableRegistryBoot

MasterServers REG_BINARY Durchgezählte Reihe roher IP-Adressen Default: (Einen Vorgabewert für diesen Eintrag gibt es nicht.)

Dieser Wert gibt diejenigen DNS-Master-Server an, von denen der Sekundär-Server die aktuelle Zonenversion sowie die Zonenübertragungen erhält. Der Werteeintrag von »MasterServers« ist erforderlich um einen »Secondary Server« mit Werten aus der Registry zu starten. Wird der DNS-Dienst gestartet mit Daten aus einer Boot-Datei, wird die in der Boot-Datei hinterlegte Liste der Master-Server ausgelesen und als Wert in den Eintrag »MasterServers« geschrieben, wobei eine ggf. bereits vorhandene Liste überschrieben wird. Dieser Wert wird erst ab Windows NT 4.0 (oder später) unterstützt. Es ist nicht möglich, IP-Adressen in der Dezimalform »dotted decimal« zu schreiben. Um die Einträge von »MasterServers« zu ändern, sollte die entsprechende Tabelle »General« in »Zone Properties« (Zoneneigenschaften) im DNS-Manager verwendet werden; dort tauchen die IP-Adressen in der gewohnten Form »dotted decimal« auf. Im Hintergrund werden dann die IP-Adressen konvertiert, wenn sie in die Registry geschrieben werden. Siehe auch: EnableRegistryBoot

SecondaryServers REG_BINARY Durchgezählte Reihe roher IP-Adressen. Default: (Keine Server aufgeführt.)

688

DNS Zones

Dieser Wert führt die Sekundär-Server auf, die der Master-Server benachrichtigt, wenn eine neue Version der Zone vorhanden ist. (Dabei muss es sich nicht notwendig um eine vollständige Liste aller Sekundär-Server einer Zone handeln). Ist der Wert des Eintrages »SecureSecondaries« auf »1« gesetzt, werden die Zonenübermittlungen nur an die in der Liste aufgeführten Server durchgeführt. Dieser Wert wird nur verwendet, wenn ein Master-Server mit Werten aus der Registry startet. Die Quelle der Startdaten von DNS sind hinterlegt in »EnableRegistryBoot«. Dieser Eintrag bzw. sein Wert sollte nicht gelöscht werden. Ist dieser Eintrag in der Registry nicht vorhanden, schaltet DNS die Funktion »SecureSecondaries« aus. Um die Liste »SecondaryServers« zu löschen bzw. zu leeren, sollte dies über den DNS-Manager geschehen in der Tabelle »Notify« (Benachrichtigen) innerhalb von »Zone Properties« (Zoneneigenschaften). Dieser Wert wird erst ab Windows NT 4.0 (oder später) unterstützt. Es ist nicht möglich, IP-Adressen in der Dezimalform »dotted decimal« zu schreiben. Um die Einträge von »SecondaryServers« zu ändern, sollte die entsprechende Tabelle »Notify« (Benachrichtigen) in »Zone Properties« (Zoneneigenschaften) im DNS-Manager verwendet werden; dort tauchen die IP-Adressen in der gewohnten Form »dotted decimal« auf. Im Hintergrund werden dann die IPAdressen konvertiert, wenn sie in die Registry geschrieben werden. Siehe auch: EnableRegistryBoot SecureSecondaries

SecureSecondaries REG_DWORD 0 | 1 Default: 0

Dieser Wert gibt an, ob die Eigenschaft »SecureSecondaries« (abgesicherte Sekundär-Server) eingeschaltet ist (oder nicht). Wert

Bedeutung

0

SecureSecondaries = AUS. Zonenübertragungen werden an alle Sekundär-Server geschickt, die das verlangen.

Tab. A.60: SecureSecondaries-Werte

Anhang A • Die Registry von Windows NT

689

Wert

Bedeutung

1

SecureSecondaries = EIN. Zonenübertragungen werden nur an diejenigen Server vorgenommen, deren IP-Adresse in der Liste »SecondaryServers« aufgeführt ist. Ist diese Liste leer (sind also keine IP-Adressen aufgeführt), werden keine Zonenübertragungen durchgeführt.

Tab. A.60: SecureSecondaries-Werte (Forts.)

Die Funktion »SecureSecondaries« stellt sicher, dass Zonenübertragungen nur an genau die Server gehen, die ausdrücklich dafür vorgesehen sind. Die Liste der Server, die Zonenübertragungen erhalten, wird erzeugt im DNS-Manager, Tabelle »Notify« (Benachrichtigen), »Zone Properties« (Zonen-Eigenschaften); diese Liste liegt im Eintrag »SecondaryServers« und darf nicht leer sein. Die Funktion »SecureSecondaries« erlaubt eine genaue Einschränkung der Zonenübertragungen auf nur die Server, die darauf angewiesen sind. Außerdem vermindert eine Einschränkung gemäß »SecureSecondaries« und »SecondaryServers« den Verbrauch an Prozessorzeit und vermindert die Gefahr von »Denial-Of-Service«Attacken, auch »SYN-Flooding« genannt (das massenhafte Aufkommen von TCP-Versuchen zum Verbindungsaufbau per »Synchronize«-Befehl). Die Werteeinträge dieses Unterschlüssels werden benötigt, wenn der DNS Master-Server mit Werten aus der Registry startet. Um die Quelldaten beim DNSBoot festzulegen, ist der Eintrag »EnableRegistryBoot« zu bearbeiten. Wird der Wert von »EnableRegistryBoot« auf »0« gesetzt, werden der Unterschlüssel »Zones« und sein sämtlicher Inhalt gelöscht. Erscheint »SecondaryServers« nicht in der Registry, wird die Funktion »SecureSecondaries« von DNS ausgeschaltet. Dieser Wert wird erst ab Windows NT 4.0 (oder später) unterstützt. Um Änderungen vorzunehmen sollte der DNS-Manager aufgerufen werden, Tabelle »Notify« (Benachrichtigen), »Zone Properties« (Zonen-Eigenschaften).

Type REG_DWORD 0 | 1 | 2 Default: (Einen Vorgabewert für diesen Eintrag gibt es nicht.)

Dieser Wert gibt den Typ der Zone an, die im aktuellen Unterschlüssel beschrieben wird. Er gibt die Datei an, die ausgelesen wird zum Laden einer Zone, wenn der DNS-Dienst mit Werten aus der Registry startet. Wird DNS gestartet mit Daten aus einer Boot-Datei, wird die Zonenangabe aus dieser Boot-Datei in den Eintrag »Type« geschrieben; ein ggf. bereits vorhandener Wert für »Tpye« wird hierbei überschrieben.

690

InetInfo

Wert

Bedetung

0

Cache Datei (oder Root-Hint-Datei)

1

Primär-Zone

2

Sekundär-Zone

Tab. A.61: Type-Werte

Dieser Wert wird erst ab Windows NT 4.0 (oder später) unterstützt. Um Änderungen vorzunehmen sollte der DNS-Manager aufgerufen werden, Tabelle »General« (Allgemein), »Zone Properties« (Zoneneigenschaften). Dieser Eintrag bzw. sein Wert sollte nicht gelöscht werden; er wird von DNS beim Starten benötigt.

UseDatabase REG_DWORD 0 | 1 Default: 0

Dieser Wert wird mit der Installation angelegt, aber nicht verwendet. Dieser Wert wird erst ab Windows NT 4.0 (oder später) unterstützt.

A.14 InetInfo HKEY_LM\System\CurrentControlSet\Services\InetInfo\Parameters AcceptExOutstanding AcceptExTimeout BandwidthLevel CacheSecurityDescriptor DisableMemoryCache ListenBackLog LogFileBatchSize LogFileFlushInterval MaxPoolThreads MemoryCacheSize MinFileKbSec ObjectCacheTTL PoolThreadLimit ThreadTimeout UseAcceptEx UserTokenTTL Tab. A.62: Registry-Schlüssel für InetInfo

Anhang A • Die Registry von Windows NT

691

Global Entries for Internet Information Server Die Werteeinträge des Registry-Unterschlüssels »Inetinfo\Parameters« speichern Einstellungen für/von FTP (File Transfer Protocol), Gopher und WWW-Dienste/n (World Wide Web) des »Internet Information Servers«, etwa HTTP (Hypertext Transfer Protocol). IIS = Internet Information Server

AcceptExOutstanding REG_DWORD 0 – 1000 freie Sockets Default: 40

Dieser Wert gibt die Mindestanzahl freier Sockets an, die verwaltet werden müssen, wenn »AcceptEx« verwendet wird. IIS verwaltet freie Sockets in der Weise, dass es immer bereit ist Anfragen zu neuen Verbindungen anzunehmen und zu prozessieren. Wenn die Zahl freier Sockets unter die in »AcceptExOutstanding« angegebenen Wert fällt, wird IIS weitere Sockets einrichten, um die Mindestanzahl freier Sockets wieder herzustellen. »AcceptEx« ist eine Eigenschaft zur Optimierung von IIS; es erlaubt IIS, eine neue Verbindung herzustellen und die initiale Datenanforderung im selben Schritt zu lesen. Um den Wert dieses Eintrages zu ändern, muss die Registry editiert werden; sodann muss IIS beendet und neu gestartet werden. Der Internet Service Manager kann hierzu nicht verwendet werden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: AcceptExTimeout UseAcceptEx

AcceptExTimeout REG_DWORD 0x0 – 0xFFFFFFFF Sekunden Default: 0x78 (2 Minuten)

Dieser Wert gibt die Zeit an, die ein AcceptEx-Socket wartet, um eine Empfangsoperation zu vollenden. Wenn der Empfangsvorgang länger dauert, als der Wert von »AcceptExTimeout« zulässt, beendet IIS die Verbindung. Eine Begrenzung des Zeitwertes für Empfangsvorgänge verbessert die Leistungskraft der IIS-Sokkets und vermindert den Verbrauch an Systemspeicher.

692

InetInfo

Um den Wert dieses Eintrages zu ändern muss die Registry editiert werden; sodann muss IIS beendet und neu gestartet werden. Der Internet Service Manager kann hierzu nicht verwendet werden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: AcceptExOutstanding UseAcceptEx

BandwidthLevel REG_DWORD 0x0 – 0xFFFFFFFE KiloBytes pro Sekunde | 0xFFFFFFFF Default: 0xFFFFFFFF

Dieser Wert aktiviert den »IIS Bandwidth Throttler« und spezifiziert den maximalen Netzwerkdurchsatz, der vom Dienst des Internet Information Server in Anspruch genommen werden kann. Die Begrenzung des Durchsatzes verhindert, dass IIS einen unverhältnismäßig hohen Anteil am Netzwerkverkehr verursacht bzw. für sich beansprucht. Typischerweise ist der IIS-Durchsatz begrenzt, um anderen Diensten genügend Durchsatz zu belassen, etwa E-Mail. Der Wert »BandwidthLevel« begrenzt die Datenmenge, die der IIS-Dienst sendet. Die angegebene Durchsatzmenge beinhaltet nicht die Protokoll-Header und Steuer-Bits, die mit den Daten verbunden sind. Wert

Bedeutung

0x0 – 0xFFFFFFFE KiloBytes pro Sekunde

Der »IIS Bandwidth Throttler« berechnet laufend die Datenmenge, die vom IIS-Dienst gesendet wird. Wenn die Datenmenge den Grenzwert »BandwidthLimit« erreicht oder überschreitet, weist der »Bandwidth Throttler« Sendezugriffe zurück, bis der erforderliche Durchsatz wieder zur Verfügung steht.

0xFFFFFFFF

Der von IIS verwendete Durchsatz wird nicht begrenzt.

Tab. A.63: BandwidthLevel-Werte

Um den Wert dieses Eintrages zu ändern, muss die Registry editiert werden; sodann muss IIS beendet und neu gestartet werden. Es wird empfohlen, den Internet Service Manager zu verwenden um den Wert zu ändern. Im »Eigenschaften«-Dialog des IIS-Dienstes kann das eingestellt werden (»Properties« / »Advanced« / »Limit Network Use by all Internet Services on this

Anhang A • Die Registry von Windows NT

693

computer« / »Maximum Network Use«). Die Änderung bezieht sich auf FTP, Gopher und WWW zugleich; es spielt darum keine Rolle, bei welchem der drei Dienste der Wert geändert wird.

CacheSecurityDescriptor REG_DWORD 0 | 1 Default: 0

Der Wert gibt an, ob IIS Sicherheitsbeschreibungen für Dateiobjekte im MemoryCache gespeichert werden. Das Speichern von Sicherheitsbeschreibungen (»security descriptors«) ist eine Eigenschaft, die auf jeden IIS-Server eingeschaltet sein sollte, der »non-anonymous user« bedient bzw. zulässt. Wert

Bedeutung

0

Der Internet Information Server (IIS) hält keine Sicherheitsbeschreibungen im Cache. Stattdessen wird die Sicherheitsbeschreibung für ein Objekt jedesmal neu erstellt, wenn die Zugriffsrechte eines neuen Anwenders geprüft werden.

1

Der Internet Information Server (IIS) hält für Dateiobjekte die Sicherheitsbeschreibung im Cache. Dies erlaubt dem IIS, Zugriffsrechte für andere Benutzer zu prüfen, ohne das Dateiobjekt erneut zu öffnen.

Tab. A.64: CacheSecurityDescriptor-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Die Internet Information Server 2.0 und 3.0 erneuern die Sicherheitsbeschreibungen nicht (»do not update security descriptors«), während diese im Cache gehalten werden. Wenn die Benutzerrechte geändert werden, könnten einige Sicherheitsbeschreibungen veraltet sein (weil sie die Änderungen nicht enthalten). Um die Sicherheitsbeschreibungen per Update zu erneuern muss ISS beendet und neu gestartet werden.

DisableMemoryCache REG_DWORD 0 | 1 Default: 0

694

InetInfo

Dieser Wert gibt vor, ob IIS die gerade verwendeten Objekte im »IIS Object Cache« speichert. Der IIS Object Cache ist darauf ausgelegt, die Leistung des IIS zu verbessern. Ein Ausschalten des Cache-Speichers wird nicht empfohlen. Wert

Bedeutung

0

IIS speichert im IIS Object Cache die Objekte, auf die kürzlich zugegriffen wurde oder die aufwendig zu berechnen sind, etwa Dateizugriffsschlüssel (»file handles«), Verzeichnislisten (»directory listings«) oder »parsed Internet Database Connector queries« und ihre Ergebnisse.

1

IIS hält keine Objekte im Cache.

Tab. A.65: DisableMemoryCache-Werte

Um den Wert dieses Eintrages zu ändern, muss die Registry editiert werden; sodann muss IIS beendet und neu gestartet werden. Der Internet Service Manager kann hierzu nicht verwendet werden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: MemoryCacheSize ObjectCacheTTL

ListenBackLog REG_DWORD 1 – 250 Default: 15

Verbindungs-Anforderungen

Dieser Wert gibt die maximale Anzahl aktiver Verbindungsanforderungen an, die in den Warteschlangen des IIS-Dienstes gehalten werden können. Verbindungsanforderungen an den IIS-Dienst werden solange in Warteschlangen gehalten, bis der Dienst auf die Anforderung antworten kann. Ungeachtet der Tatsache, dass verschiedene IIS-Dienste jeweils eigene Warteschlangen für Verbindungsanforderungen haben, ist die maximale Länge aller Warteschlangen identisch und wird durch den Wert des Eintrages »ListenBackLog« gesetzt. Ist die Warteschlange eines Dienstes voll, werden die nächsten Anforderungen zurückgewiesen. Die vorgegebene Länge der Warteschlange ist mit 15 Verbindungsanforderungen für die meisten Server ausreichend. Wird beobachtet, dass viele Anforderungen zurückgewiesen werden, kann der Wert entsprechend angehoben werden. Jedoch sollte der Maximalwert von 250 nicht überschritten werden.

Anhang A • Die Registry von Windows NT

695

Um den Wert dieses Eintrages zu ändern, muss die Registry editiert werden; sodann muss IIS beendet und neu gestartet werden. Der Internet Service Manager kann hierzu nicht verwendet werden.

LogFileBatchSize REG_DWORD 0x2 – 0xFFFFFFFF Default: 0x40 (64 KB)

KiloBytes

Dieser Wert gibt die Verarbeitungsgröße vor, die IIS anzeigt, Log-Daten auf die Festplatte zu schreiben. Jeder IIS-Dienst nimmt Log-Einträge vor bezüglich der Verbindungs- und Seitenanforderungen. Wenn der Dienst Daten für die Log-Dateien sammelt, werden die Daten zunächst nacheinander im physikalischen Hauptspeicher abgelegt, genannt »Batch Memory«. Von dort werden die Log_Daten in Dateien geschrieben, wenn die »LogFileBatchSize« erreicht ist, oder wenn die maximale Wartezeit »LogFileFlushInterval« erreicht bzw. überschritten ist. Ein großer Batch-Speicher erspart zu viele Festplattenzugriffe. Andererseits kann ein großer Batch-Speicher den Hauptspeicher insgesamt zu sehr belasten. Entsprechend kann es sinnvoll sein, diesen Batch-Speicher mal größer, mal kleiner zu halten. Um den Wert dieses Eintrages zu ändern, muss die Registry editiert werden; sodann muss IIS beendet und neu gestartet werden. Der Internet Service Manager kann hierzu nicht verwendet werden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

LogFileFlushInterval REG_DWORD 0x3C – 0xFFFFFFFE Sekunden | 0xFFFFFFFF Default: 0x12C (300 Sekunden = 5 Minuten)

Dieser Wert gibt vor, wie oft Log-Einträge, die im Hauptspeicher liegen (»BatchSpeicher«), auf die Festplatte geschrieben werden. Siehe hierzu die Details in »LogFileBatchSize«.

696

InetInfo

Wert

Bedeutung

0x3C – 0xFFFFFFFE Sekunden (1 Minute und mehr)

Gibt an, wie oft die Log-Einträge auf die Festplatte geschrieben werden. Dieser Wert ist auf weniger aktive Server zugeschnitten, bei denen die Batch-Größe den Maximalwert regelmäßig eher nicht erreicht.

0xFFFFFFFF

Das Intervall zum Wegschreiben der Log-Einträge auf die Festplatte ist bedeutungslos. IIS schreibt die Log-Einträge nur dann auf die Festplatte, wenn die höchstzulässige Größe erreicht ist (kein Zeitintervall).

Tab. A.66: LogFileFlushInterval-Werte

Um den Wert dieses Eintrages zu ändern, muss die Registry editiert werden; sodann muss IIS beendet und neu gestartet werden. Der Internet Service Manager kann hierzu nicht verwendet werden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

MaxPoolThreads REG_DWORD 0x0 – 0xFFFFFFFF Default: 0xA (10)

Threads

Dieser Wert gibt die maximale Anzahl von IIS Pool-Threads an, die zugleich am selben Prozessor bearbeitet werden können. Ein Thread im IIS-Pool beobachtet die Verbindungsanforderungen. Die verbleibenden Threads bearbeiten die Verbindungs- und Datenanforderungen. Es sollten nicht mehr als 20 Threads je Prozessor eingerichtet werden. Um den Wert dieses Eintrages zu ändern, muss die Registry editiert werden; sodann muss IIS beendet und neu gestartet werden. Der Internet Service Manager kann hierzu nicht verwendet werden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: PoolThreadLimit

Anhang A • Die Registry von Windows NT

697

MemoryCacheSize REG_DWORD 0 | 0x1 – 0xFFFFFFFF Bytes Default: (10 Prozent des physikalischen Speichers)

Dieser Wert gibt die Größe des »IIS Object Cache« an. Wert (in Bytes)

Bedeutung

0

IIS speichert die Cache-Objekte nicht. Da der IIS Object Cache die Systemleistung verbessert, wird von einem Abschalten abgeraten.

0x1-0xFFFFFFFF

IIS speichert die Cache-Objekte; der Wert gibt die Größe des IIS Object Cache an.

Tab. A.67: MemoryCacheSize-Werte

Wenn der Server über genügend physikalischen Speicher verfügt, könnte die IISLeistung verbessert werden durch eine Vergrößerung des IIS Object Cache. Um herauszufinden, wie oft der Server den IIS Object Cache benutzt, muss am »Performance Monitor« nachgesehen werden unter: »Internet Information Server Global: Cache Used«. Um den Wert dieses Eintrages zu ändern, muss die Registry editiert werden; sodann muss IIS beendet und neu gestartet werden. Der Internet Service Manager kann hierzu nicht verwendet werden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: DisableMemoryCache ObjectCacheTTL

MinFileKbSec REG_DWORD 1 – 8192 Bytes pro Sekunde Default: 1000

Dieser Wert gibt die langsamste, gerade noch hinnehmbare Datenrate an für Dateien, die vom Server gesendet werden. Der Wert von »MinFileKbSec« wird verwendet, um festzulegen, wie lange Dateiübertragungen andauern dürfen, bevor sie abgebrochen werden. Um festzustellen, wie lange ein Sendevorgang (noch) andauern darf, dividiert IIS die Größe der Datei (in Bytes) durch »MinFileKbSec«. Für die Entscheidung selber wird dann entweder das Ergebnis dieser

698

InetInfo

Berechnung herangezogen oder der Wert von »ConnectionTimeout«; der jeweils größere Wert wird als maximal zulässige Zeit zur Dateiübertragung angesehen. Diese Methode gibt mehr Zeit zum Senden großer Dateien. Alle Sendevorgänge dürften äußerstenfalls bis zur Zeitüberschreitung andauern, aber großen Dateien wird eine Zusatzzeit gewährt, abhängig von der niedrigsten, gerade noch hinnehmbaren Datenrate, festgelegt in »MinFileKbSec«. Beispiel: Wenn »ConnectionTimeout« auf 900 Sekunden festgesetzt ist und »MinFileKbSec« auf 1.000 Bytes pro Sekunde, so wird IIS 900 Sekunden (15 Minuten) zulassen für die Übertragung einer 100-Kbyte-Datei, aber 2.048 Sekunden (34 Minuten) für eine 2-Mbyte-Datei. »MinFileKbSec« wird berechnet in Bytes pro Sekunde, nicht Kilobytes pro Sekunde, wie der Name nahe legt. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

ObjectCacheTTL REG_DWORD 0x0 | 0x1 – 0x7FFFFFFF Sekunden | 0xFFFFFFFF Default: 0x1E (30 Sekunden)

Dieser Wert legt fest, wie lange »unreferenced objects« (gewissermaßen »tote Einträge«) im IIS Object Cache verbleiben. Wurde auf ein Objekt über die mit »ObjectCacheTTL« angegebene »Lebenszeit« hinaus nicht mehr zugegriffen, wird das Objekt im IIS Object Cache gelöscht. Wert

Bedeutung

0

IIS führt keinen Object Cache.

0x1 – 0x7FFFFFFF Sekunden

Die maximale Zeit, die »tote« Objekte (»unreferenced objects«) im IIS Object Cache verbleiben dürfen.

0xFFFFFFFF

Objekte verleiben im IIS Object Cache, bis sie dort überschrieben werden.

Tab. A.68: ObjectCacheTTL-Werte

Wenn der physikalische Speicher des Servers begrenzt ist, sollte über eine Verminderung des Wertes von »ObjectCacheTTL« nachgedacht werden. Ist genügend physikalischer Speicher vorhanden, so kann mit einer Erhöhung des Wertes eines Leistungssteigerung erreicht werden.

Anhang A • Die Registry von Windows NT

699

Um den Wert dieses Eintrages zu ändern, muss die Registry editiert werden; sodann muss IIS beendet und neu gestartet werden. Der Internet Service Manager kann hierzu nicht verwendet werden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: DisableMemoryCache MemoryCacheSize

PoolThreadLimit REG_DWORDRange 0x0 – 0xFFFFFFFF Threads Default: (Summe des physikalschen Speichers in Mbyte) x 2

Dieser Wert gibt die maximale Anzahl von IIS Pool-Threads an, die zeitgleich am selben Prozessor bearbeitet werden können. Ein Thread im IIS-Pool beobachtet die Verbindungsanforderungen. Die verbleibenden Threads bearbeiten die Verbindungs- und Datenanforderungen. Der Vorgabewert ist ein Maximum von zwei Threads für jedes MegaByte physikalischen Speichers. Beispiel: Wenn ein Rechner über 32 Mbyte Hauptspeicher verfügt, läge das vorgegebene Limit bei 64 Threads. Dieser Wert ist für die meisten Server hinreichend geeignet. Eine Änderung des Wertes kann die Leistung des IIS beeinträchtigen. Um den Wert dieses Eintrages zu ändern, muss die Registry editiert werden; sodann muss IIS beendet und neu gestartet werden. Der Internet Service Manager kann hierzu nicht verwendet werden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: MaxPoolThreads

ThreadTimeout REG_DWORD 0x0 – 0xFFFFFFFF Sekunden Default: 0x 15180 (86.400 Sekunden = 24 Stunden)

Dieser Wert gibt die Zeit an, die IIS einen I/O-Thread verwaltet, wenn am System keine I/O-Aktivitäten stattfinden. Ist die mit »ThreadTimeout« angegebene Zeit

700

InetInfo

abgelaufen, wird der Thread angehalten. Allgemein gilt: Wenn keine I/O-Aktivitäten stattfinden, stehen auch keine Anforderungen aus; der Server ist dann frei und verbraucht keinen Speicher. Um den Wert dieses Eintrages zu ändern, muss die Registry editiert werden; sodann muss IIS beendet und neu gestartet werden. Der Internet Service Manager kann hierzu nicht verwendet werden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

UseAcceptEx REG_DWORD 0 | 1 Default: 1

Dieser Wert gibt an, ob die »AcceptEx«-Eigenschaft verwendet wird (oder nicht). Wenn »AcceptEx« eingeschaltet ist, stellt IIS eine neue Verbindung her und liest die zugehörigen Initialdaten im selben Schritt. Ist »AcceptEx« abgeschaltet, wird die Datenanforderung in einem getrennten Schritt verarbeitet. Wert

Bedeutung

0

AcceptEx = AUS

1

AcceptEx = EIN

Tab. A.69: UseAcceptEx-Werte

AcceptEx dient der Verbesserung von IIS. Ein Abschalten von AcceptEx könnte die Systemleistung vermindern. Um den Wert dieses Eintrages zu ändern, muss die Registry editiert werden; sodann muss IIS beendet und neu gestartet werden. Der Internet Service Manager kann hierzu nicht verwendet werden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: AcceptExOutstanding AcceptExTimeout

Anhang A • Die Registry von Windows NT

701

UserTokenTTL REG_DWORD 0x0 | 0x1 – 0x7FFFFFFF Sekunden. Default: 0x384 (900 Sekunden = 15 Minuten)

Dieser Wert gibt an, wie lange IIS »unreferenced security tokens« (gewissermaßen wegen Nicht-Gebrauchs »tote« Sicherheitsschlüssel) im IIS Object Cache speichert. Wenn ein Security Token über die mit »UserTokenTTL« festgesetzte Zeit nicht verwendet wurde, löscht IIS das Token aus dem IIS Object Cache. Wert

Bedeutung

0x0

IIS legt das Security Token nicht in den Cache.

0x1 – 0x7FFFFFFF Sekunden

Der Wert gibt die maximale Lebensdauer für »tote« Security Tokens an (»unreferenced security tokens«).

Tab. A.70: UserTokenTTL-Werte

»Security Tokens« stellen Zugriffsschlüssel gegenüber dem Anwender dar, die ausgegeben werden, wenn auf Dateien der sonstige System-Ressourcen zugegriffen wird. Das Token wird im IIS Object Cache abgelegt; mit dem Token können mehrere Zugriffe in Folge abgewickelt werden. Windows NT »Challenge/ Response authentication tokens« werden jedoch nicht im Cache abgelegt. Wenn der Systemspeicher knapp ist oder wenn die Anwender viele Seiten einzeln bzw. einmalig abfordern, kann eine Erhöhung des Wertes von »UserTokenTTL« die Leistung von IIS verbessern. Um den Wert dieses Eintrages zu ändern, muss die Registry editiert werden; sodann muss IIS beendet und neu gestartet werden. Der Internet Service Manager kann hierzu nicht verwendet werden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

A.15 IP RIP HKEY_LM\System\CurrentControlSet\Services\IpRip\Parameters AcceptDefaultRoutes AcceptHostRoutes AnnounceDefaultRoutes AnnounceHostRoutes Tab. A.71: Registry-Schlüssel für IP RIP

702

IP RIP

HKEY_LM\System\CurrentControlSet\Services\IpRip\Parameters EnablePoisonedReverse EnableSplitHorizon EnableTriggeredUpdates GarbageTimeout LoggingLevel MaxTriggeredUpdateFrequency RouteTimeout SilentRip UpdateFrequency Tab. A.71: Registry-Schlüssel für IP RIP (Forts.)

Dieser Abschnitt beschreibt die Registry-Einträge für das »Routing Information Protocol« (RIP) für das »Internet Protocol« (IP). Wenn beim Windows NT Server das »Multiprotocol Routing« aktiviert und RIP verwendet wird, können Datenpakete von einem Netzwerkadapter zum anderen vermittelt werden unter Verwendung von RIP-für-IP oder RIP-für-IPX (Internetwork Packet Exchange).

AcceptDefaultRoutes REG_DWORD 0 | 1 Default: 0

Dieser Wert legt fest, ob sog. »Default Routes« in den RIP-Mitteilungen, die der Server erhält, berücksichtigt oder übergangen werden. »Default Routes« sind vorgegebene IP-Wege, die zu einem IP-Subnetz führen. Wert

Bedeutung

0

»Default routes« in empfangenen RIP-Paketen werden übergangen.

1

»Default routes« in empfangenen RIP-Paketen weren berücksichtigt.

Tab. A.72: AcceptDefaultRoutes-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: AnnounceDefaultRoutes AcceptHostRoutes

Anhang A • Die Registry von Windows NT

703

AcceptHostRoutes REG_DWORD 0 | 1 Default: 0

Dieser Wert legt fest, ob sog. »Host Routes« in den RIP-Mitteilungen, die der Server erhält, berücksichtigt oder übergangen werden. »Host Routes« sind vorgegebene IP-Wege, die zu einem IP-Endgerät führen. Wert

Bedeutung

0

»Host routes« in empfangenen RIP-Paketen werden übergangen.

1

»Host routes« in empfangenen RIP-Paketen weren berücksichtigt.

Tab. A.73: AcceptHostRoutes-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: AnnounceHostRoutes AcceptDefaultRoutes

AnnounceDefaultRoutes REG_DWORD 0 | 1 Default: 0

Dieser Wert legt fest, ob sog. »default routes« in den RIP-Mitteilungen, die der Server sendet, enthalten sein sollen. Wert

Bedeutung

0

»Default routes« sind in gesendeten RIP-Paketen nicht enthalten.

1

»Default routes« sind in gesendeten RIP-Paketen enthalten.

Tab. A.74: AnnounceDefaultRoutes-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

704

IP RIP

Siehe auch: AcceptDefaultRoutes AnnounceHostRoutes

AnnounceHostRoutes REG_DWORD 0 | 1 Default: 0

Dieser Wert legt fest, ob sog. »Host Routes« in den RIP-Mitteilungen, die der Server sendet, enthalten sein sollen. Wert

Bedeutung

0

»Host routes« sind in gesendeten RIP-Paketen nicht enthalten.

1

»Host routes« sind in gesendeten RIP-Paketen enthalten.

Tab. A.75: AnnounceHostRoutes-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: AcceptHostRoutes AnnounceDefaultRoutes

EnablePoisonedReverse REG_DWORD 0 | 1 Default: 1

Dieser Wert gibt an, ob die Eigenschaft »poison reverse« verwendet werden soll (oder nicht). Wenn diese Funktion genutzt wird, melden Router immer die von anderen Routern gelernten Routen über dasselbe Netzwerk an diese zurück unter Verwendung eines Metric-Wertes von 16 (»unreachable« oder »infinity«). Dies hindert die Router daran, RIP-Mitteilungen über diese Route an den Absender zurückzuschicken. Dies schützt ebenfalls den Eintritt eines Zählerüberlaufs zu »unendlich«, was geschehen kann, wenn ein Router oder eine Verbindung innerhalb der Schleife (»loop«) ausgefallen sind. Bei einem Zählerüberlauf zu »unendlich« melden Router steigende Metric-Werte zurück an die Router, welche diese Information gemeldet hatten, bis der Wert 16 erreicht wird.

Anhang A • Die Registry von Windows NT

705

Wert

Bedeutung

0

AUS: Die Funktion »poison reverse« ist ausgeschaltet. Router melden den korrekten Metric-Wert für jede Route, selbst dann, wenn die RIP-Meldung zurückgeht an den Router, von dem die Route gelernt wurde. Wenn ein Router ausfällt oder der Wert von »EnableSplitHorizon« auf »0« fällt, meldet der Router für diese Route steigende Metric-Werte. Dieser gestiegene Wert kann zum Eintreten der »count to infinity condition« führen, innerhalb derer der Router für die betroffene Route immer weitersteigende Metric-Werte meldet, bis der Wert von 16 erreicht ist.

1

EIN: Die Funktion »poison reverse« ist eingeschaltet. Routers melden immer einen Metric-Wert von 16 bei Routen, die sie von einem Router im selben Netzwerk (im selben Segment bzw. Subnetz) gelernt haben.

Tab. A.76: EnablePoisonedReverse-Werte

»EnablePoisonedReverse« arbeitet mit »EnableSplitHorizon« zusammen um zu verhindern, dass Meldungen zu einer Route zum Urheber (einem anderen Router) zurückgeschickt werden. »EnablePoisonedReverse« verhindert Routing-Schleifen (»loops«) zwischen mehreren Routern. »EnableSplitHorizon« verhindert Routing-Schleifen zwischen zwei nebeneinander liegenden Routern (»prevents routing loops between two adjacent routers«).. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor, oder über sonstige, geeignete Software.

EnableSplitHorizon REG_DWORD 0 | 1 Default: 1

Dieser Wert gibt an, ob Routen, die von benachbarten Routern in einem Netzwerk gelernt wurden, in Update-Meldungen innerhalb dieses Netzwerkes mitgeteilt oder unterdrückt werden sollen. Dies kann verhindern, dass eine Route zu genau dem Router gemeldet wird, von dem sie gelernt wurde. Wert

Bedeutung

0

Routen, die von benachbarten Routern gelernt wurden, werden gemeldet.

1

Routen, die von benachbarten Routern gelernt wurden, werden unterdrückt.

Tab. A.77: EnableSplitHorizon-Werte

706

IP RIP

»EnablePoisonedReverse« arbeitet mit »EnableSplitHorizon« zusammen um zu verhindern, dass Meldungen zu einer Route zum Urheber (einem anderen Router) zurückgeschickt werden. »EnablePoisonedReverse« verhindert Routing-Schleifen (»loops«) zwischen mehreren Routern. »EnableSplitHorizon« verhindert Routing-Schleifen zwischen zwei nebeneinander liegenden Routern (»prevents routing loops between two adjacent routers«). Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

EnableTriggeredUpdates REG_DWORD 0 | 1 Default: 1

Legt fest, ob die Funktion »Triggered Updates« ein- oder ausgeschaltet ist. Wenn sie genutzt wird, können RIP-Router Veränderungen in den Route-Metrics melden, sobald es ihm gestattet ist, anstatt auf die vorgesehene, planmäßige Zeit für die nächste RIP-Meldung zu warten (typischerweise 30 Sekunden). Die Zeit zwischen planmäßigen Update-Meldungen hängt an vom Wert in »MaxTriggeredUpdateFrequency«. »Triggered Updates« verbessern die Abstimmung zwischen RIP-Netzwerken durch kürzere Abgleichzeiten; andererseits erhöht das Verfahren das BroadcastAufkommen. Wert

Bedeutung

0

AUS – Es werden keine »triggered updates« durchgeführt. Der Router muss warten bis zur nächsten planmäßigen Rundsendung, um Änderungen in Route-Metrics zu melden.

1

EIN – Es werden »triggered updates« durchgeführt. Der Router kann Änderungen nahezu unverzüglich melden.

Tab. A.78: EnableTriggeredUpdates-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

Anhang A • Die Registry von Windows NT

707

GarbageTimeout REG_DWORD 15-259.200 Sekunden (bis zu 72 Stunden) Default: 120

Dieser Wert gibt an, wie lange das System wartet, bis eine Route gelöscht wird, die für diese Löschung markiert wurde. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: RouteTimeout

LoggingLevel REG_DWORD 0 | 1 | 2 | 3 Default: 1

Dieser Wert gibt an, ob IP-RIP Meldungen in das System-Ereignis-Log geschrieben werden sollen. Wert

Bedeutung

0

Kein Logging

1

Nur Fehler

2

Fehler und Warnungen

3

Fehler, Warnungen und sonstige Benachrichtigungen

Tab. A.79: LoggingLevel-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

MaxTriggeredUpdateFrequency REG_DWORD 1-86.400 Sekunden (bis zu 24 Stunden) Default: 5

708

IP RIP

Dieser Wert gibt die Mindestzahl der Sekunden an, die zwischen »triggered updates« verstrichen sein müssen. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

RouteTimeout REG_DWORD 15-259.200 Sekunden (bis zu 72 Stunden) Default: 180

Dieser Wert gibt an, wie lange das System einer unbenutzten Route erlaubt aktiv zu bleiben. Wenn der Wert von »RouteTimeout« überschritten ist (also eine Zeitüberschreitung gegeben ist), wird die Route markiert und zur Löschung vorgesehen. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: GarbageTimeout

SilentRip REG_DWORD 0 | 1 Default: 0

Dieser Wert gibt an, ob periodische RIP-Meldungen gesendet oder unterdrückt werden sollen. Wert

Bedeutung

0

EIN – sendet periodische RIP-Meldungen (»announcements«).

1

AUS – unterdrückt periodische RIP-Meldungen.

Tab. A.80: SilentRip-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

Anhang A • Die Registry von Windows NT

709

UpdateFrequency REG_DWORD 15-86.400 Sekunden (bis zu 24 Stunden) Default: 30

Dieser Wert gibt an, wie oft das System Update-Meldungen der gesamten Routing-Tabelle versendet. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

A.16 LanMan Server HKEY_LM\System\CurrentControlSet\Services\LanmanServer\Parameters MaxPagedMemoryUsage MaxNonpagedMemoryUsage Tab. A.81: Registry-Schlüssel für LanMan Services

WinNT-Server allocieren nicht von vornherein den verfügbaren Speicher für den Server-Dienst. Oft bleibt Speicher ungenutzt und der Server wird langsam, weil er sich mit Swapping behelfen muss. Eine Anpassung dieses Wertes an den physikalisch tatsächlich verfügbaren Speicher kann den Server-Dienst erheblich beschleunigen.

MaxNonpagedMemoryUsage REG_DWORD 0x100000 – 0xFFFFFFFF bytes Default: (Depends on system and server configuration.)

Der Wert dieses Eintrages gibt die Höchstmenge an »NonPaged Memory« an, den der Server-Dienst zu einer Zeit belegen darf.

MaxPagedMemoryUsage REG_DWORD 0x100000 – 0xFFFFFFFF bytes Default: (Depends on system and server configuration.)

710

MUP – Multiple UNC Provider

Der Wert dieses Eintrages gibt die Höchstmenge an »Pageable Memory« an, den der Server-Dienst zu einer Zeit belegen darf.

A.17 MUP – Multiple UNC Provider HKEY_LM\System\CurrentControlSet\Services\Mup DisableDfs Tab. A.82: Registry-Schlüssel für MUP

MUP Service Entries Der Registry-Unterschlüssel »MUP« enthält Konfigurationsdaten für den »Multiple UNC Provider« Datei-System-Treiber MUP.SYS.

DisableDfs REG_DWORD 0 | 1 Default: 0

Dieser Wert gibt an, ob der Dienst des »Distributed File Systems« (DFS) ein/aus geschaltet ist. DFS ist normalerweise eingeschaltet. Es kann aber möglicherweise angeraten sein, DFS abzuschalten, um Clients davon abzuhalten, DFS-Freigabenamen aufzulösen oder um Netzwerkverkehr in Verbindung mit DFS abzustellen. Wert

Bedeutung

0

Distributed File System (DFS) – EIN

1

Distributed File System (DFS) – AUS

Tab. A.83: DisableDfs-Werte

Da die Client-Komponente von DFS im Treiber MUP.SYS enthalten ist, wird MUP von DFS erfordert. Ist der Wert von »DisableDfs« auf »0« gesetzt, wird MUP.SYS automatisch gestartet, – selbst dann, wenn der Wert für »Start« im MUP-Unterschlüssel auf »3« (manuell) gesetzt ist. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

Anhang A • Die Registry von Windows NT

711

A.18 NBF – NetBEUI Transport Frames HKEY_LM\System\CurrentControlSet\Services\NBF\Parameters AddNameQueryRetries AddNameQueryTimeout DefaultT1Timeout DefaultT2Timeout DefaultTiTimeout GeneralRetries GeneralTimeout InitAddresses InitAddressFiles InitConnections InitLinks InitPackets InitReceiveBuffers InitReceivePackets InitRequests InitUIFrames LLCMaxWindowSize LLCRetries MaxAddresses MaxAddressFiles MaxConnections MaximumIncomingFrames MaxLinks MaxMemoryUsage MaxRequests NameQueryRetries NameQueryTimeout QueryWithoutSourceRouting ReceivePacketPoolSize SendPacketPoolSize UseDixOverEthernet WanNameQueryRetries Tab. A.84: Registry-Schlüssel für NBF – NetBEUI Transport Frames

NBF – NetBEUI Transport Frames Der Registry-Unterschlüssel NBF\Parameters enthält Startparameter für den NetBEUI-Transport (NBF). Die Einträge von NBF, die mit »Init...« beginnen, legen fest, wie viel freien Speicher die NBF-Komponenten beim Start belegen. Die Einträge von NBF, die mit »Max...« beginnen, legen die maximale Speichermenge fest, die NBF belegen darf.

712

NBF – NetBEUI Transport Frames

Das NBF-System belegt selbsttätig den benötigten Speicher innerhalb der mit »Init...« und »Max...« festgelegten Grenzen. Per Vorgabe belegt das NBF-System nur so viel Ressourcen, wie zur Bearbeitung der Client-Anforderungen erforderlich sind. Ist es nicht aktiv, belegt es auch nicht viele Ressourcen. Wenn der Server allgemein stark ausgelastet ist, kann über eine Erhöhung der »Init..«-Werte nachgedacht werden. Dann sollten auch die »Max...«-Werte angepasst werden; allerdings muss sichergestellt sein, dass NBF nicht zu viel Systemspeicher verbraucht. Siehe auch: NetRules

AddNameQueryRetries REG_DWORD 0x0 – 0xFFFFFFFF Default: 0x3

Dieser Wert gibt die Anzahl der Versuche an, mit denen NBF Pakete mit den Meldungen ADD_NAME_QUERY und ADD_GROUP_NAME_QUERY sendet, wenn keine Antworten eintreffen. Dieser Wert sollte nur verändert (erhöht) werden, wenn NBF NetBIOS-Adressen registrieren will in einem Netzwerk, in dem viele Pakete verloren gehen.

AddNameQueryTimeout REG_DWORD Wartezeit, dargestellt als Mehrfaches von je 100 NanoSekunden Default: 5.000.000 (500 Milli-Sekunden)

Dieser Wert gibt an, wie lange NBF zwischen den einzelnen Sendevorgängen wartet, wenn schrittweise Pakete mit den Meldungen ADD_NAME_QUERY und ADD_GROUP_NAME_QUERY gesendet werden. Dieser Wert sollte nur verändert (erhöht) werden, wenn NBF Adressen registrieren will in einem Netzwerk, in dem viele Pakete verloren gehen.

DefaultT1Timeout REG_DWORD Wartezeit, dargestellt als Mehrfaches von je 100 NanoSekunden Default: 6.000.000 (600 Milli-Sekunden)

Anhang A • Die Registry von Windows NT

713

Dieser Wert gibt den Initial-Wert an für die T1-Zeitüberschreitung. Die T1-Zeitüberschreitung legt fest, wie lange NBF auf die Antwort der Gegenstelle wartet, nachdem ein LLC-Paket (Logical Link Control) mit »Poll«-Befehl gesendet wurde, bevor es wiederholt gesendet wird. Dieser Wert sollte nur dann verändert (erhöht) werden, wenn NBF mit Paketwiederholungen arbeitet (weil keine Antworten eingingen) bzw. wenn sich die Antworten wegen langsamer Leitungen und/oder langsamer Rechner auf der Gegenseite verzögern. NBF passt sich den Erfordernissen weitgehend selber an; sollte dies nicht ausreichen, kann der Wert verändert werden. Siehe auch:

LLCRetries

DefaultT2Timeout REG_DWORD Wartezeit, dargestellt als Mehrfaches von je 100 NanoSekunden Default: 1.500.000 (150 Milli-Sekunden)

Dieser Wert gibt den Initial-Wert an für die T2-Zeitüberschreitung. Die T2-Zeitüberschreitung legt fest, wie lange NBF mit der eigenen Antwort wartet, nachdem ein LLC-Paket (Logical Link Control) mit »Poll«-Befehl empfangen wurde. Der Wert von »DefaultT2Timeout« muss mindestens halb so groß sein wie der Wert in »DefaultT1Timeout«. Dieser Wert sollte nur dann verändert (erhöht) werden, wenn NBF mit Paketwiederholungen arbeitet (weil keine Antworten eingingen) bzw. wenn sich die Antworten wegen langsamer Leitungen und/oder langsamer Rechner auf der Gegenseite verzögern. NBF passt sich den Erfordernissen weitgehend selber an; sollte dies nicht ausreichen, kann der Wert verändert werden. Siehe auch: DefaultT1Timeout

DefaultTiTimeout REG_DWORD Wartezeit, dargestellt als Mehrfaches von je 100 NanoSekunden Default: 300.000.000 (30 Sekunden)

Dieser Wert gibt den Initial-Wert an für die Ti-Zeitüberschreitung. Die Ti-Zeitüberschreitung gibt an, wie lange eine LLC-Verbindung (»link«) inaktiv sein darf, bevor NBF ein LLC-»Poll«-Paket sendet, um sicherzustellen, dass die LLC-Verbindung immer noch aufrecht erhalten wird (werden soll).

714

NBF – NetBEUI Transport Frames

Dieser Wert sollte nur dann verändert (erhöht) werden, wenn NBF wiederholt LLC-»Poll«-Pakete sendet oder wenn NBF inaktive LLC-Verbindungen nicht als solche erkennt. NBF passt sich den Erfordernissen weitgehend selber an; sollte dies nicht ausreichen, kann der Wert verändert werden.

GeneralRetries REG_DWORD 0x0 – 0xFFFFFFFF Default: 0x3

Dieser Wert gibt an, wie oft NBF maximal Pakete schickt mit den Meldungen STATUS_QUERY und FIND_NAME, wenn von der Gegenstelle keine Antworten eingehen. Dieser Wert sollte nur verändert (erhöht) werden, wenn NBF Adressen registrieren will in einem Netzwerk, in dem viele Pakete verloren gehen.

GeneralTimeout REG_DWORD Wartezeit, dargestellt als Mehrfaches von je 100 NanoSekunden Default: 5.000.000 (500 Milli-Sekunden)

Dieser Wert gibt an, wie lange NBF wartet zwischen zwei Übertragungsvorgängen, wenn schrittweise Pakete gesendet werden mit den Meldungen (bzw. Anforderungen) STATUS_QUERY und FIND_NAME. Dieser Wert sollte nur verändert (erhöht) werden, wenn NBF NetBIOS-Adressen registrieren will in einem Netzwerk, in dem viele Pakete verloren gehen.

InitAddresses REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x0

Dieser Startwert legt die initiale Anzahl der NBF-Adressen fest. Adressen entsprechen den NetBIOS-Namen. Das System belegt Speicher für NBF, um beim Start die Anzahl der Adressen zu speichern, die im Wert »InitAddress« angegeben ist. Im weiteren Betrieb von NBF belegt das System weiteren Speicher, wenn dies für weitere Adressen notwendig ist. Allerdings ist die Gesamtmenge der Adressen beschränkt durch den von NBF insgesamt belegten Speicher.

Anhang A • Die Registry von Windows NT

715

Wert

Bedeutung

0x0

Es wird kein Speicher im Voraus für Adressen belegt. Das System belegt Speicher für Adressen nach Bedarf und Anlass.

0x1-0xFFFFFFFF

Für die angegebene Anzahl von Adressen wird Speicher belegt, wenn NBF startet.

Tab. A.85: InitAddresses-Werte

Die Erhöhung dieses Wertes kann angemessen sein, wenn NBF eine ungewöhnlich große Zahl von Adressen verwalten muss. Siehe auch: MaxAddresses

InitAddressFiles REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x0

Dieser Startwert gibt die initiale Anzahl von Adressdateien für NBF an. Das System belegt für NBF Speicher, um die dem Startwert entsprechende Anzahl von Adressdateien zu halten. Im weiteren Betrieb belegt das System weiteren Speicher für Adressdateien je nach Bedarf und Anlass. Die Adressdatei muss in den insgesamt von NBF belegten Speicher passen. Wert

Bedeutung

0x0

Es wird kein Speicher im Voraus für Adressdateien belegt. Das System belegt Speicher für Adressdateien nach Bedarf und Anlass.

0x1-0xFFFFFFFF

Für die angegebene Anzahl von Adressdateien wird Speicher belegt, wenn NBF startet.

Tab. A.86: InitAddressFiles-Werte

Siehe auch: MaxAddressFiles

InitConnections REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x1

716

NBF – NetBEUI Transport Frames

Dieser Startwert gibt die initiale Anzahl an Verbindungen (»connections«) für NetBIOS-Sitzungen an. Das System belegt für NBF Speicher, um beim Start von NBF die dem Startwert entsprechende Anzahl von Verbindungen zu halten. Im weiteren Betrieb belegt das System weiteren Speicher für Verbindungen je nach Bedarf und Anlass. Die Verbindungen müssen in den insgesamt von NBF belegten Speicher passen. Wert

Bedeutung

0x0

Es wird kein Speicher im Voraus für Verbindungen belegt. Das System belegt Speicher für Verbindungen nach Bedarf und Anlass.

0x1-0xFFFFFFFF

Für die angegebene Anzahl von Verbindungen wird Speicher belegt, wenn NBF startet.

Tab. A.87: InitConnections-Werte

Siehe auch: MaxConnections Anmerkung zu »Links« und »Connections« (S. 725))

InitLinks REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x2

Dieser Startwert gibt die initiale Anzahl an LLC-Verbindungen (»links«) an. Das System belegt für NBF Speicher, um beim Start von NBF die dem Startwert entsprechende Anzahl von LLC-Verbindungen zu halten. Im weiteren Betrieb belegt das System weiteren Speicher für Verbindungen je nach Bedarf und Anlass. Die LLC-Verbindungen müssen in den insgesamt von NBF belegten Speicher passen. Wert

Bedeutung

0x0

Es wird kein Speicher im Voraus für LLC-Verbindungen belegt. Das System belegt Speicher für LLC-Verbindungen nach Bedarf und Anlass.

0x1-0xFFFFFFFF

Für die angegebene Anzahl von LLC-Verbindungen wird Speicher belegt, wenn NBF startet.

Tab. A.88: InitLinks-Werte

Weil der Redirector alle LLC-Verbindungen (»links«) zu einer Gegenstelle innerhalb derselben logischen Verbindung (»connection«) verwaltet, erzeugt der Server für gewöhnlich für jeden LLC-Link eine eigene logische Verbindung zur

Anhang A • Die Registry von Windows NT

717

Gegenstelle. In jedem Falle gilt: Wenn zwei Rechner miteinander kommunizieren oder wenn eine NetBIOS-Anwendung läuft, könnten mehrere Verbindungen (»connections«) je LLC-Link gegeben sein. Es kann angemessen sein, den Wert für »InitLinks« zu erhöhen, wenn eine große Zahl von LLC-Links benötigt wird. Siehe auch: MaxLinks Anmerkung zu »Links« und »Connections« (S. 725)

InitPackets REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x1E (30)

Dieser Startwert gibt die initiale Anzahl von Transport-Paketen an sowie die Mindestzahl von Paketen, die während des Sendevorgangs verwaltet werden. Das System belegt für NBF Speicher, um beim Start von NBF die dem Startwert entsprechende Anzahl von Paketen zu halten. Im weiteren Betrieb belegt das System weiteren Speicher für Pakete je nach Bedarf und Anlass. Wert

Bedeutung

0x0

Es wird kein Speicher im Voraus für Pakete belegt. Das System belegt Speicher für Pakete nach Bedarf und Anlass.

0x1-0xFFFFFFFF

Für die angegebene Anzahl von Paketen wird Speicher belegt, wenn NBF startet.

Tab. A.89: InitPackets-Werte

NBF benutzt Transportpakete, um die Daten einer logischen Verbindung (»connection«) zu einem Client zu senden. Das System belegt Transportpakete nach Bedarf; gleichwohl kann ggf. eine Anpassung des Startwertes »InitPackets« angemessen sein. Dies kann der Fall sein, wenn viele Fehlermeldungen mit dem Inhalt »Send Packets Exhausted« auftreten oder wenn der Zähler »Times Exhausted« in »NetBEUI Resource« innerhalb des »Performance Monitors« ungewöhnlich hohe Werte anzeigt. Siehe auch: Anmerkung zu »Links« und »Connections« (S. 725) Anmerkung zu »NBF« und »Transport« (S:726)

InitReceiveBuffers REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x5

718

NBF – NetBEUI Transport Frames

Dieser Startwert gibt die initiale Anzahl der Empfangspuffer an. Das System belegt für NBF Speicher, um beim Start von NBF die dem Startwert entsprechende Anzahl von Empfangspuffer zu halten. Im weiteren Betrieb belegt das System weiteren Speicher für Empfangspuffer je nach Bedarf und Anlass. Wert

Bedeutung

0x0

Es wird kein Speicher im Voraus für Eingangspuffer belegt. Das System belegt Speicher für Eingangspuffer nach Bedarf und Anlass.

0x1-0xFFFFFFFF

Für die angegebene Anzahl von Eingangspuffern wird Speicher belegt, wenn NBF startet.

Tab. A.90: InitReceiveBuffers-Werte

NBF verwendet Empfangspuffer, wenn es die NDIS-Funktion »TransferData« für eingehende Pakete aufruft. Der Wert von »InitReceiveBuffers« kann erhöht werden, wenn NBF ungewöhnlich viele Datagramm-Pakete erhält. Siehe auch: Anmerkung zu LLC »Datagrams« (S. 726)

InitReceivePackets REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0xA (10)

Dieser Startwert gibt die initiale Anzahl der Empfangspakete an sowie die Mindestzahl, die während des Betriebs verwaltet wird. Das System belegt für NBF Speicher, um beim Start von NBF die dem Startwert entsprechende Anzahl von Empfangspaketen zu halten. Im weiteren Betrieb belegt das System weiteren Speicher für Empfangspuffer je nach Bedarf und Anlass. Die Pakete müssen in den von NBF insgesamt belegten Speicher passen. Wert

Bedeutung

0x0

Es wird kein Speicher im Voraus für Eingangspakete belegt. Das System belegt Speicher für Eingangspakete nach Bedarf und Anlass.

0x1-0xFFFFFFFF

Für die angegebene Anzahl von Eingangspaketen wird Speicher belegt, wenn NBF startet.

Tab. A.91: InitReceivePackets-Werte

NBF verwendet »Transport Receive Packets« um Daten vom NDIS-Treiber abzufragen. Eine Verminderung des Wertes kann angemessen sein, wenn NBF ungewöhnlich wenige Pakete mit Anwendungsdaten erhält. Auch die Erhöhung des

Anhang A • Die Registry von Windows NT

719

Wertes kann angemessen sein. Dies kann der Fall sein, wenn viele Fehlermeldungen des Inhalts »Send Packets Exhausted« auftreten oder wenn der Zähler »Times Exhausted« in »NetBEUI Resource« innerhalb des »Performance Monitors« ungewöhnlich hohe Werte anzeigt.

InitRequests REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x5

Dieser Startwert gibt die initiale Anzahl der Anforderungen (»requests«) an. Das System belegt für NBF Speicher, um beim Start von NBF die dem Startwert entsprechende Anzahl von Anforderungen zu halten. Im weiteren Betrieb belegt das System weiteren Speicher für Anforderungen je nach Bedarf und Anlass. Die Anforderungen müssen in den von NBF insgesamt belegten Speicher passen. »Anforderungen« werden verwendet für Vorgänge wie »In-Progress Connect Requests« (Vorbereitungsphase des Verbindungsaufbaus), »Remote Adapter Status Requests« (Anfragen nach dem Verbindungsstatus auf Seite der Gegenstelle) und »Find Name Requests« (Rundrufe im Netzwerk um einen bestimmten NetBIOS-Namen zu finden). Wert

Bedeutung

0x0

Es wird kein Speicher im Voraus für Anforderungen belegt. Das System belegt Speicher für Anforderungen nach Bedarf und Anlass.

0x1-0xFFFFFFFF

Für die angegebene Anzahl von Anforderungen wird Speicher belegt, wenn NBF startet.

Tab. A.92: InitRequests-Werte

InitUIFrames REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x5

Dieser Startwert gibt die initiale Anzahl der LLC-UI-Pakete an (UI = Unnumbered Information). Das System belegt für NBF Speicher, um beim Start von NBF die dem Startwert entsprechende Anzahl von LLC-UI-Paketen zu halten. Im weiteren Betrieb belegt das System weiteren Speicher für Anforderungen je nach Bedarf und Anlass. Die LLC-UI-Pakete müssen in den von NBF insgesamt belegten Speicher passen.

720

NBF – NetBEUI Transport Frames

»LLC-UI-Pakete« werden verwendet für Vorgänge wie Verbindungsaufbau und Verbindungsdienste (wie die Übersendung von Datagrammen). Üblicherweise belegt das System für die LLC-UI-Pakete Speicher je nach Bedarf und Anlass; eine Erhöhung des Startwertes kann angemessen sein, wenn große Mengen von LLC-UI-Paketen anfallen. Wert

Bedeutung

0x0

Es wird kein Speicher im Voraus für LLC-UI-Pakete belegt. Das System belegt Speicher für LLC-UI-Pakete nach Bedarf und Anlass.

0x1-0xFFFFFFFF

Für die angegebene Anzahl von LLC-UI-Paketen wird Speicher belegt, wenn NBF startet.

Tab. A.93: InitUIFrames-Werte

LLCMaxWindowSize REG_DWORD Number of frames Default: 10

Dieser Wert gibt die Zahl von LLC-I-Paketen an (I = Information), die NBF senden kann, bevor eine Antwort der Gegenstelle abgefordet bzw. abgewartet wird. Dieser Wert sollte nicht verwendet werden, es sei denn, NBF würde über ein Netzwerk arbeiten, über das die Antworten der Gegenstelle nur unzuverlässig zurückgelangen.

LLCRetries REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x8

Dieser Wert gibt die maximale Zahl der Versuche an, mit denen NBF nach einer T1-Zeitüberschreitung die Gegenstelle ruft. Wird die in »LLCRetries« angegebene Zahl der Wiederholungen erreicht bzw. überschritten, wird die Verbindung aufgegeben. Dieser Wert sollte nicht verwendet werden, es sei denn, NBF würde über ein Netzwerk arbeiten, über das die Antworten der Gegenstelle nur unzuverlässig zurückgelangen.

Anhang A • Die Registry von Windows NT

721

Wert

Bedeutung

0x0

Es gibt keine Begrenzung in der Zahl der Wiederholungsversuche.

0x10xFFFFFFFF

Der Wert stellt die maximale Anzahl der Wiederholungsversuche dar. Nach Erreichen dieses Maximums wird die LLC-Verbindung aufgegeben.

Tab. A.94: LLCRetries-Werte

Siehe auch: DefaultT1Timeout

MaxAddresses REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x0

Dieser Wert gibt die maximale Anzahl von NBF-Adressen an, für die Speicher belegt wird. Die gesamte Anzahl der Adressen muss in den insgesamt von NBF belegten Speicher passen. »Adressen« entsprechen den NetBIOS-Namen. Eine »Adresse« ist für den aktuellen Namen und eine »Adressdatei« ist für einen TDI-Client (Transport Driver Interface), der den Namen benutzt; üblicherweise ist die Zahl für »Adresse« und »Adressdatei« identisch, aber wenn zwei Benutzer dieselbe Adresse öffnen, haben zwei Adressdateien ein und dieselbe Adresse. Wert

Bedeutung

0x0

Es gibt keine Beschränkung in der Anzahl der Adressen.

0x1-0xFFFFFFFF

Der Wert stellt die maximale Anzahl der Adressen dar.

Tab. A.95: MaxAddresses-Werte

Siehe auch: InitAddresses

MaxAddressFiles REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x0

Dieser Wert gibt die maximale Anzahl von NBF-Adressdateien an, für die Speicher belegt wird. Die gesamte Anzahl der Adressdateien muss in den insgesamt von NBF belegten Speicher passen.

722

NBF – NetBEUI Transport Frames

»Adressen« entsprechen den NetBIOS-Namen. Eine »Adresse« ist für den aktuellen Namen und eine »Adressdatei« ist für einen TDI-Client (Transport Driver Interface), der den Namen benutzt; überlicherweise ist die Zahl für »Adresse« und »Adressdatei« identisch, aber wenn zwei Benutzer dieselbe Adresse öffnen, haben zwei Adressdateien ein und dieselbe Adresse. Wert

Bedeutung

0x0

Es gibt keine Beschränkung in der Anzahl der Adressdateien.

0x1-0xFFFFFFFF

Der Wert stellt die maximale Anzahl der Adressdateien dar.

Tab. A.96: MaxAddressFiles-Werte

Siehe auch: InitAddressFiles

MaxConnections REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x0

Dieser Wert gibt die maximale Anzahl von NBF-Verbindungen (»connections«) an, für die Speicher belegt wird. Die gesamte Anzahl der NBF-Verbindungen muss in den insgesamt von NBF belegten Speicher passen. NBF-Verbindungen werden eingerichtet zwischen NBF-Clients und gleichwertigen Gegenstellen auf Netzwerkrechnern (»similar entities on remote computers«). Wert

Bedeutung

0x0

Es gibt keine Beschränkung in der Anzahl der NBF-Verbindungen.

0x1-0xFFFFFFFF

Der Wert stellt die maximale Anzahl der NBF-Verbindungen dar.

Tab. A.97: MaxConnections-Werte

Siehe auch: InitConnections Anmerkung zu »Links« und »Connections« (S. 728)

MaximumIncomingFrames REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x4

Anhang A • Die Registry von Windows NT

723

Dieser Wert gibt an, wie viele NDIS-Pakete NBF empfängt, bevor es an die Gegenstelle eine Empfangsquittung (»Acknowledgment«) sendet. Wert

Bedeutung

0x0

NBS verwendet interne Algorithmen um zu errechnen, wann eine Quittung gesendet wird.

0x1-0xFFFFFFFF

Der Wert stellt die Anzahl der eingegangenen Pakete dar, mit deren Erreichen das Senden der Quittung ausgelöst wird.

Tab. A.98: MaximumIncomingFrames-Werte

»MaxIncomingFrames« ist ähnlich, aber nicht identisch, mit dem »MaxIn«-Parameter des »Microsoft LAN Managers«. Kommuniziert der Windows NT Server mit einem Rechner, der mit »Microsoft LAN Manager« oder »Microsoft LAN Server« arbeitet und der zudem mit einem niedrigen »MaxOut«-Wert eingerichet ist, kann die Gesamtleistung verbessert werden, indem der Wert »MaxIncomingFrames« kleiner oder gleich ist mit dem »MaxOut«-Wert der Gegenstelle(n). Siehe auch: Anmerkung zu »Links« und »Connections« (siehe S. 728)

MaxLinks REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x0

Dieser Wert gibt die maximale Anzahl an LLC-Verbindungen (»links«) an, für die NBF Speicher belegt. Die LLC-Verbindungen müssen in den insgesamt von NBF belegten Speicher passen. LLC-Links werden für jeden Adapter einer Gegenstelle einrichten, mit der kommuniziert wird. Üblicherweise wird der Wert des Eintrages »MaxLinks« verwendet um Link-Ressourcen mit einem unbegrenzten NBF zu steuern. Wert

Bedeutung

0x0

Es gibt keine Begrenzung für die Anzahl von LLC-Verbindungen.

0x1-0xFFFFFFFF

Maximale Anzahl von LLC-Verbindungen (»links«).

Tab. A.99: MaxLinks-Werte

Siehe auch: InitLinks Anmerkung zu »Links« und »Connections« (S. 728)

724

NBF – NetBEUI Transport Frames

MaxMemoryUsage REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF bytes Default: 0x0

Dieser Wert gibt die maximale Speichermenge an, die NBF belegen kann. Diese Obergrenze gilt für sämtlichen Speicher, der von der Summe aller NBF-Benutzer belegt wird. Wert

Bedeutung

0x0

Es gibt keine Begrenzung für die Belegung von Speicher durch NBF. Das System entscheidet selber, wie viel Speicher NBF zugewiesen werden kann.

0x1-0xFFFFFFFF

Maximale Anzahl des Speichers, der von NBF belegt werden kann.

Tab. A.100: MaxMemoryUsage-Werte

MaxRequests REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x0

Dieser Wert gibt die maximale Anzahl an Anforderungen (»requests«) an, für die NBF Speicher belegt. Die Anforderungen müssen in den insgesamt von NBF belegten Speicher passen. Anforderungen werden von NBF verwendet um das Senden, Empfangen, Verbinden und Warten innerhalb von Datendialogen zu steuern. Wert

Bedeutung

0x0

Es gibt keine Begrenzung für die Anzahl von Anforderungen.

0x1-0xFFFFFFFF

Maximale Anzahl von Anforderungen (»requests«).

Tab. A.101: MaxRequests-Werte

Siehe auch: InitRequests

Anhang A • Die Registry von Windows NT

725

NameQueryRetries REG_DWORD 0x0 – 0xFFFFFFFF Default: 0x3

Dieser Wert gibt an, wie oft höchstens die Aussendung einer NAME_QUERY wiederholt wird, wenn keine Antwort eingeht. Eine Erhöhung dieses Wertes ist nur dann ratsam, wenn NBF über Netzwerke arbeitet, in denen viele Pakete verloren gehen.

NameQueryTimeout REG_DWORD 0x0 – 0xFFFFFFFF Wartezeit in Einheiten von je 100 NanoSekunden Default: 0x4C4B40 (5.000.000 Einheiten = 500 Millisekunden)

Dieser Wert legt die Zeit fest zwischen den einzelnen Übertragungen von schrittweise gesendeten NAME_QUERY-Paketen. Dieser Wert sollte nur dann angehoben werden, wenn NBF mit langsamen Gegenstellen oder über langsame Netzwerke arbeitet.

QueryWithoutSourceRouting REG_DWORD 0 | 1 Default: 0

Dieser Wert legt fest, ob NBF Anfragen (»queries«) mit Source-Routing-Information sendet. Dieser Eintrag bzw. sein Wert hat nur Wirkung, wenn NBF über einen Token-Ring-Treiber arbeitet. Der Wert von »QueryWithoutSourceRouting« kann auf »1« gesetzt werden, um Bridges zu unterstützen, die keine Source-RoutingInformation verarbeiten und also Source-Route-Pakete nicht weiterleiten können. Wert

Bedeutung

0

NBF sendet alle Anfragen (»queries«) mit Source-Routing-Information.

1

NBF sendet alle Anfragen zur Hälfte mit, zur Hälfte ohne Source-RoutingInformation, wenn die Verbindung zu einer Gegenstelle aufgebaut wird.

Tab. A.102: QueryWithoutSourceRouting-Werte

726

NBF – NetBEUI Transport Frames

ReceivePacketPoolSize REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x1E (30)

Pakete

Dieser Wert gibt die Anzahl von NDIS Empfangspaketen an (»NDIS Receive Packets«), die dem »NDIS Receive Packet Pool« zugeordnet werden, wenn das System startet. Der Wert von »ReceivePacketPoolSize« gibt außerdem die maximale Anzahl von Aufrufen von NDS an zur Überweisung von Paketen an den »Initial Receive Packet Pool«; die Anzahl der Pools wird dadurch nicht begrenzt, ebensowenig die Anzahl der NDIS-Aufrufe zur Übergabe von Paketen an untergeordnete Pools. Wert

Bedeutung

0x0

Das System errechnet eine Eingangsgröße des Pools (»initial pool size«) und passt die Größe im laufenden Betrieb den Erfordernissen an.

0x1-0xFFFFFFFF

Richtet die Zahl der Pakete ein, die dem Paket-Pool zugeordnet sind, wenn das System startet, und zugleich die maximale Anzahl von NDIS-Aufrufen zur Bearbeitung von Paketen. Dieser Wert von »ReceivePacketPoolSize« übergeht den vom System errechneten Wert und hält das System davon ab, selbsttätig den Wert anzupassen.

Tab. A.103: ReceivePacketPoolSize-Werte

Eine Änderung dieses Wertes kann zur Folge haben, dass NBF den Speicher weniger effizient verwaltet.

SendPacketPoolSize REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x64 (100 packets)

Pakete

Dieser Wert gibt die Anzahl von NDIS Sendepaketen an (»NDIS Send Packets«), die dem »NDIS Send Packet Pool« zugeordnet werden, wenn das System startet. Der Wert von »SendPacketPoolSize« gibt außerdem die maximale Anzahl von Aufrufen von NDS an zur Überweisung von Paketen an den »Initial Send Packet Pool«; die Anzahl der Pools wird dadurch nicht begrenzt, ebensowenig die Anzahl der NDIS-Aufrufe zur Übergabe von Paketen an untergeordnete Pools.

Anhang A • Die Registry von Windows NT

727

Wert

Bedeutung

0x0

Das System errechnet eine Eingangsgröße des Pools (»initial pool size«) und passt die Größe im laufenden Betrieb den Erfordernissen an.

0x1-0xFFFFFFFF

Richtet die Zahl der Pakete ein, die dem Paket-Pool zugeordnet sind, wenn das System startet, und zugleich die maximale Anzahl von NDIS-Aufrufen zur Bearbeitung von Paketen. Dieser Wert von »ReceivePacketPoolSize« übergeht den vom System errechneten Wert und hält das System davon ab, selbsttätig den Wert anzupassen.

Tab. A.104: SendPacketPoolSize-Werte

Eine Änderung dieses Wertes kann zur Folge haben, dass NBF den Speicher weniger effizient verwaltet.

UseDixOverEthernet REG_DWORD 0 | 1 Default: 0

Dieser Wert gibt an, ob NBF das Ethernet-Coding nach DIX oder nach IEEE 802.3 verwendet werden soll, wenn es über Ethernet arbeitet bzw. an eine Ethernet MAC-Adresse gebunden ist (MAC = Media Access Control). Wenn das Coding nach DIX eingestellt ist, kann der Rechner nicht mit Gegenstellen »sprechen«, die nach IEEE 802.3 arbeiten. Wert

Bedeutung / Frame Format

0

NBF arbeitet nach IEEE 802.3.

1

NBF arbeitet nach DIX.

Tab. A.105: UseDixOverEthernet-Werte

Siehe auch: Anmerkung zu »DIX« (S. 729)

WanNameQueryRetries REG_DWORD 0x0 – 0xFFFFFFFF Default: 0x5

Dieser Wert gibt die maximale Zahl der Versuche von NBS an, Pakete mit NAME_QUERY zu senden, wenn bei einem Versuch des Verbindungsaufbaus via

728

NBF – NetBEUI Transport Frames

Dieser Wert sollte nur dann verändert (erhöht) werden, wenn NBF über ein Netzwerk arbeitet, in dem viele Pakete verloren gehen.

Anmerkungen des Autors Die folgenden Anmerkungen kommentieren die Beschreibungen, die für »NBF – NetBEUI Framing Protocol« zunächst den Microsoft-Quellen entnommen worden waren. Die vielen Ungereimtheiten erzwangen nicht nur Korrekturen in den Beschreibungen, sondern auch diese zusätzlichen Anmerkungen. »Links« und »Connections« Während eindeutig mit »link« die Verbindung auf LLC-Ebene bezeichnet wird, ist unklar, ob mit »Connection« die Verbindung auf NetBIOS-Ebene gemeint ist. Die Microsoft-Quellen haben hier einen unklaren Sprachgebrauch. Unter »MaxConnections« wurde/wird von Microsoft folgende Erklärung geboten: »Connections are established between NBF clients and similar entities on remote computers.« Dies legt einerseits nahe, dass es sich bei »Connection« um NetBIOSDialoge handelt, andererseits ist völlig unklar, was man sich unter »similar entities« vorzustellen hat. Unter »Entity« wird überlicherweise das Vorkommnis (»instance«) eines geladenen Protokolltreibers verstanden. Welcher Nicht-NetBIOS-Treiber denn mit NetBIOS kommunizieren könnte, ist nicht nachzuvollziehen. Hierzu kann allenfalls hilfsweise eine Erklärung unter »MaximumIncomingFrames« dienen: Dort wird auf Unterschiede zwischen NBF und älteren Versionen des Microsoft LAN Manger oder Microsoft LAN Server hingewiesen. LLC »Datagrams«: Die Microsoft-Beschreibung ist missverständlich. Als »Datagramme« werden Pakete innerhalb einer verbindungslosen Datenübertragung bezeichnet bzw. solche Pakete, die ohne eine logische Sitzung zwischen Dialogpartnern gesendet werden. Da NBF aber NetBEUI beschreibt bzw. NetBIOS-over-LLC-2 und somit seitens LLC einen verbindungsorientierten Dienst, ist der obige Satz zweifelhaft, dass der Empfangspuffer zu erhöhen sei, wenn »ungewöhnlich viele DatagramPakete« eingehen (»InitReceiveBuffers«). »NBF Transport«: Es ist in den NBF-Beschreibungen von Microsoft mehrfach die Rede von »Transportpaketen« oder vom »NBF-Transport«. Hier muss klargestellt sein, dass im engeren Sinn kein Protokoll der Transportschicht (OSI Layer 4) vorhanden ist. Die für die Transportprotokolle typischen Funktionen der Data Flow Control sind bei NBF vorhanden, wenn über LLC-2 gearbeitet wird; ansonsten liegen Mechanismen der Datenflusskontrolle im SMB-Protokoll (Server Message Block). Der Sprachgebrauch hierzu ist bei Microsoft höchst missverständlich.

Anhang A • Die Registry von Windows NT

729

»DIX« DEC-Intel-Xerox legten Anfang der 80er Jahre das Konzept zu »Ethernet II« vor, das dann beim IEEE Grundlage von »802.3 CSMA/CD« wurde.

A.19 NetBT – NetBIOS over TCP/IP HKEY_LM\System\CurrentControlSet\Services\NetBT\Parameters BacklogIncrement BcastNameQueryCount BcastQueryTimeout BroadcastAddress CacheTimeout DhcpNodeType DhcpScopeId EnableDns EnableLmhosts EnableProxy EnableProxyRegCheck InitialRefreshTimeout LmhostsTimeout MaxConnBackLog MaxDgramBuffering NameServerPort NameSrvQueryCount NameSrvQueryTimeout NbProvider NodeType RandomAdapter RefreshOpCode ScopeId SessionKeepAlive SingleResponse Size/Small/Medium/Large TransportBindName WinsDownTimeout Tab. A.106: Registry-Schlüssel für NetBT NetBIOS over TCP/IP

NetBT (NetBIOS over TCP/IP) Parameters

730

NetBT – NetBIOS over TCP/IP

BacklogIncrement REG_DWORD 1 – 20 Default: 3

Dieser Eintrag bestimmt die Zahl der Verbindungsblöcke (»connection blocks«), um die der Server seine bestehenden vermehrt, wenn er weitere »connection blocks« braucht. Ab Windows NT 4.0 Service Pack 2 geschieht die Hinzunahme weiterer Blöcke automatisch. Jedesmal, wenn ein Verbindungsereignis eintritt und die Zahl der freien Blöcke unter 2 liegt, wird die in »BacklogIncrement« angegebene Zahl von Blöcken durch NetBT hinzugefügt. NetBT bei Windows NT 3.51 und 4.0 (ohne Service Packs) arbeiteten noch mit dem Eintrag »backlog«, der die insgesamt verfügbaren Verbindungsblöcke bezeichnete. Die Anzahl der verfügbaren Blöcke entsprach dem Basiswert 2 sowie einer inkrementellen Anzahl, die von der Menge der NetBT-Nutzer abhing, etwa dem Redirector, dem Server oder NetBIOS-Anwendungen. Auf einem typischen Server lag dieser Inkrement-Wert bei 7-11 Blöcken. Dieser Eintrag wird nur ab Windows NT 4.0 Service Pack 2 (oder später) unterstützt. Siehe auch: MaxConnBackLog

BcastNameQueryCount REG_DWORD 0x1-0xFFFF Default: 0x3

Dieser Eintrag legt die maximale Anzahl von NetBT-Broadcasts zur Namensabfrage fest. NetBT wiederholt die Broadcast-Anfragen, wenn keine Antwort eintrifft, bis zum Wert, der in »BcastNameQueryCount« angegeben ist. Siehe auch: BcastQueryTimeout

BcastQueryTimeout REG_DWORD 0x64-0xFFFFFFFF Millisekunden Default: 0x2EE (750)

Gibt die Zeit zwischen den Broadcasts an, die zur Anforderung eines einzelnen Namens gesendet werden. NetBT wiederholt die Broadcast-Anfragen, wenn keine Antwort eintrifft, bis zum Wert, der in »BcastNameQueryCount« angege-

Anhang A • Die Registry von Windows NT

731

ben ist; dieser Wert legt also fest, wann die Zeitüberschreitung bzw. die Überschreitung der Wartezeit erreicht ist. Siehe auch: BcastNameQueryCount

BroadcastAddress REG_DWORD IP-Adresse (vier Bytes / little-endian) Default: (Die Einser-Broadcast-Adresse eines jeden Netzwerkes)

Diese »BroadcastAddress« ist eine Vorgabe, mit der alle Broadcasts, die mit NetBIOS-Namens-Paketen zu tun haben, adressiert werden. Die Vorgabe ist, dass NetBT die Einer-Broadcast-Adresse verwendet, die sich aus der Netzwerkadresse ergibt. Beispiel: Bei einem Netzwerk, dessen IP-Adresse 10.101.0.0 ist und das eine SubnetzMaske von 255.255.0.0 hat, lautet die Broadcast-Adresse 10.101.255.255. Der Wert dieses Eintrags »BroadcastAddress« gilt für alle Subnetze, an die NetBT gebunden ist. Eine Änderung kann dann richtig sein, wenn das Netzwerk mit Nuller-BroadcastAdressen arbeitet (gesetzt in »UseZeroBroadcast«). Das würde bei dem oben dargestellten Beispiel bedeuten, dass die Broadcast-Adresse 101.101.0.0 lauten würde; der Wert des Eintrages »BroadcastAddress« wäre dann 0x0A650000. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

CacheTimeout REG_DWORD 0xEA60 (1 minute) – 0xFFFFFFFF Millisekunden Default: 0x927C0 (10 Minuten)

Dieser Wert legt fest, wie lange Namen in der Cache-Tabelle der Rechnernamen (NetBIOS-Namen) gehalten werden.

DhcpNodeType REG_DWORD 1 – 8 Default: 1

732

NetBT – NetBIOS over TCP/IP

Dieser Eintrag gibt den NetBT Knoten-Typ an, der via DHCP gegeben wurde. Der »Knoten-Typ« (»node type«) eines NetBT-Rechners wird gesteuert bzw. vorgegeben von zwei Einträgen, nämlich »DhcpNodeType« und »NodeType«. Der Eintrag »DhcpNodeType« wird durch DHCP verwaltet, der Eintrag »NodeType« durch den Anwender bzw. Administrator. Ist der Eintrag »NodeType« vorhanden und ist der darin enthaltene Wert gültig, geht er dem Eintrag »DhcpNodeType« vor. Die vom DHCP-Server zugewiesenen Werte können also durch die lokale Registry-Eingabe zu »NodeType« übergangen bzw. außer Kraft gesetzt werden. Der Eintrag »DhcpNodeType« wird vom DHCP-Client-Dienst gesetzt. Er sollte nicht verändert werden. Siehe auch: NodeType

DhcpScopeId REG_SZ A Punkt-getrennter Name (so wie "synapse.de "), der nicht mit einem Punkt beginnt Default: (Es gibt keinen Vorgabewert für diesen Eintrag.)

Dieser Eintrag gibt den Gültigkeitsbereich für NetBIOS-Namen für den gegebenen Knoten an. Die »ScopeId« wird gesteuert durch zwei Einträge: »DhcpScopeId« und »ScopeId«, wobei »DhcpScopeID« von DHCP gesetzt wird und »ScopeId« vom Anwender bzw. Administrator. Wenn der Eintrag »ScopeId« vorhanden und der darin enthaltene Wert gültig ist, geht es dem Wert von »DhcpScopeId« vor. Der Eintrag »DhcpScopeId« wird vom DHCP-Client-Dienst gesetzt. Er sollte nicht verändert werden. Siehe auch: ScopeID

EnableDns REG_DWORD 0 | 1 Default: 0

Dieser Eintrag legt fest, ob NetBT-Anfragen an den DNS-Server (DNS: Domain Name Service) gerichtet werden sollen, wenn die Namensauflösung über WINS, Broadcast(s) oder die LMHOSTS-Datei erfolglos waren.

Anhang A • Die Registry von Windows NT

Wert

Bedeutung

0

NEIN – NetBT richtet die Anfrage nicht an den DNS-Server.

1

JA – NetBT richtet die Anfrage auch an den DNS-Server.

733

Tab. A.107: EnableDns-Werte

Dieser Eintrag wird in der Registry erzeugt, wenn in »Systemsteuerung/Netzwerk« die Einstellungen unter »TCP/IP« vorgenommen werden. Es wird empfohlen, diesen Wert nur über »Systemsteuerung/Netzwerk« zu ändern.

EnableLmhosts REG_DWORD 0 | 1 Default: 1

Dieser Eintrag legt fest, ob eine vorhandene LMHOSTS-Datei durchsucht werden soll, wenn eine Namensauflösung über WINS oder Broadcast(s) erfolglos war. Die Vorgabe ist, dass es keine LMHOSTS-Datei gibt. Gibt es sie doch, wird ihr Pfad festgehalten im Wert von »DatabasePath«. Wert

Bedeutung

0

NEIN – NetBT durchsucht die Datei LMHOSTS nicht.

1

JA – NetBT durchsucht auch die Datei LMHOSTS.

Tab. A.108: EnableLmhosts-Werte

Dieser Eintrag wird in der Registry erzeugt, wenn in »Systemsteuerung/Netzwerk« die Einstellungen unter »TCP/IP« vorgenommen werden. Es wird empfohlen, diesen Wert nur über »Systemsteuerung/Netzwerk« zu ändern.

EnableProxy REG_DWORD 0 | 1 Default: 0

Dieser Eintrag legt fest, ob das System auf dem Netzwerk, an das NetBT gebunden ist, als Proxy Name Server arbeitet. Ein Proxy Name Server (Proxy WINS Agent) beantwortet Broadcast-Anfragen nach Namen, die er durch WINS aufgelöst hat. Durch die Verwendung eines Proxy Name Servers wird ermöglicht, dass ein Windows-Netzwerk, dessen Maschinen als BNode eingestellt sind, auf Server anderer Subnetze zugreifen kann, wenn diese über WINS bekannt sind. In diesem

734

NetBT – NetBIOS over TCP/IP

Falle versuchen die Windows-Maschinen Namensauflösungen über Broadcasts durchzuführen; Broadcasts aber sind nur auf dem lokalen Subnetz zu »hören«; der Proxy Name Server antwortet dann im lokalen Subnetz anstelle der in anderen Subnetzen liegenden Server. Wert

Bedeutung

0

NEIN – Das lokale System arbeitet nicht als Proxy Name Server.

1

JA – Das lokale System arbeitet als Proxy Name Server für die Netzwerke, auf die NetBT gebunden ist.

Tab. A.109: EnableProxy-Werte

Um diesen Wert auf Rechnern mit Windows NT 3.51 (oder früher) zu ändern, sollte »Systemsteuerung/Netzwerk« verwendet werden. Auf Maschinen mit Windows NT 4.0 muss die Registry manuell editiert werden, um einen WINS Proxy Agenten einzurichten. Siehe auch: NodeType EnableProxyRegCheck

EnableProxyRegCheck REG_DWORD 0 | 1 Default: 0

Dieser Eintrag legt fest, ob der Proxy Name Server Anfragen auf Namensanmeldung (Namensregistration bei NetBIOS/WINS) auf Konsistenz (Gültigkeit) prüft und ggf. zurückweist. »EnableProxyRegCheck« ist zunächst per Vorgabe abgeschaltet, weil sonst möglicherweise Rechner, welche die Zuteilung einer IPAdresse beantragen, keine zugeteilt bekommen, weil dieser Rechner beim lokalen WINS-Server (noch) mit einer älteren IP-Adresse eingetragen (registriert) ist. Wert

Bedeutung

0

NEIN – Der Proxy Server prüft Namensregistrationen nicht.

1

JA – Der Proxy Server prüft Namensregistrationen und lehnt sie ggf. ab, wenn der Name bereits in WINS registriert ist oder wenn der Name nicht der lokalen Namenstabelle des Proxy Servers entspricht.

Tab. A.110: EnableProxyRegCheck-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: EnableProxy

Anhang A • Die Registry von Windows NT

735

InitialRefreshTimeout REG_DWORD 0xEA600 – 0xFFFFFFF Default: 0xEA600 (16 Minuten)

Millisekunden

Dieser Wert legt den »Refresh Time-Out« fest, mit dem NetBT bei der ersten Namensanmeldung (Namensregistration bei NetBIOS/WINS) arbeitet. Der »Refresh Time-Out« ist das Intervall zwischen den wiederholten Anfragen auf Namensanmeldung, wenn der Arbeitsrechner keine Antwort auf seine Anfrage erhält. Wenn NetBT zum ersten Mal einen Namen beim WINS-Server anmeldet, versucht NetBT, den WINS-Server in Intervallen anzurufen, die einem Achtel des in »InitialRefreshTimeout« hinterlegten Wertes entsprechen. Erhält NetBT die Bestätigung einer erfolgreichen Namensanmeldung, so enthält diese Bestätigung den »Refresh Time-Out«, der für die folgenden Namenserneuerungen gelten soll. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

LmhostsTimeout REG_DWORD 0x3E8 (1 second)-0xFFFFFFFF Default: 0x1770 (6 Sekunden)

Millisekunden

Dieser Eintrag gibt an, wie lange der Client-Rechner auf die Antwort wartet nach Namensanfragen an LMHOSTS und DNS. Erhält der Client keine Antwort innerhalb der von »LmhostsTimeout« gesetzten Zeit, wird der Versuch als gescheitert angesehen. Der tatsächliche Zeitwert für das »Time-Out« wird in Einheiten gerechnet, die dem Wert dieses Eintrages entsprechen, und kann zweimal so groß sein wie der Wert dieses Eintrages. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

MaxConnBackLog REG_DWORD 1-40.000 Verbindungsblöcke ("connection blocks") Default: 1000

736

NetBT – NetBIOS over TCP/IP

Dieser Eintrag legt die Gesamtzahl der Verbindungsblöcke fest (»connection blocks«), die NetBT belegen darf. Jeder Block belegt 78 Bytes des Hauptspeichers. Sie werden anderweitig vergeben, wenn der »SYN-ACK retransmission timer« von TCP ausläuft und die TCP-Verbindung nicht zustande kam. Dieser Wert wird erst ab Windows NT 4.0 Service Pack 2 unterstützt. Siehe auch: BacklogIncrement

MaxDgramBuffering REG_DWORD 0x0-0xFFFFFFFF Bytes Default: 0x20000 (128 KB)

Dieser Eintrag gibt die Höchstmenge an Speicher an, die NetBT für ausstehende Übertragungen von Datagrammen dynamisch belegen darf. Wenn diese Obergrenze erreicht wurde, scheitern darüber hinausgehende Übertragungen am Mangel der Ressourcen. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

NameServerPort REG_DWORD 0x0-0xFFFF (UPD Port Nummer) Default: 0x89 (137)

Dieser Wert legt die Empfangs-Prozess-Kennung (Destination Port) auf dem Microsoft WINS Server fest, an den NetBT die Pakete richtet, die mit MaschinenNamen zu tun haben, etwa Anfragen auf Namensauflösung oder Namensanmeldung. Der WINS-Server ist erreichbar über Port 0x89 (137). NetBIOS Name Server anderer Hersteller verwenden möglicherweise andere Ports.

NameSrvQueryCount REG_DWORD 0x0-0xFFFF Default: 3

Dieser Eintrag legt die Zahl der Versuche fest, mit denen NetBT beim WINS-Server eine Namensauflösung anfragt.

Anhang A • Die Registry von Windows NT

737

NetBT wiederholt Anfragen, wenn sie nicht beantwortet werden, bis die Zahl der zulässigen Versuche erreicht ist.

NameSrvQueryTimeout REG_DWORD 0x64-0xFFFFFFFF Millisekunden Default: 0x5DC (1.5 Sekunden)

Dieser Eintrag legt fest, in welchem zeitlichen Abstand WINS-Anfragen zu ein und demselben Namen erfolgen. NetBT wiederholt Anfragen, wenn sie nicht beantwortet werden, bis die Zahl der zulässigen Versuche erreicht ist.

NbProvider REG_SZ String Default: _tcp

Dieser Wert wird von RPC (Remote Procedure Call) verwendet (»by the RPC component in the Windows NT Executive«) und sollte ncht verändert werden. Er legt fest, über welches Protokoll die RPCs arbeiten.

NodeType REG_DWORD Default:

1 | 2 | 4 | 8 1 | 8

Wenn weder »NodeType« noch »DhcpNodeType« in der Registry enthalten und wenn keine WINS-Server für den Client konfiguriert sind, gilt der Vorgabewert »1«. Wenn entweder »NodeType« oder »DhcpNodeType« vorhanden sind und wenigstens ein WINS-Server vorhanden ist, gilt der Vorgabewert »8«. Dieser Eintrag legt die Methode fest, mit der NetBT versucht Namen anzumelden (zu registrieren) bzw. aufzulösen. Werden LMHOSTS und/oder DNS verwendet, verwenden auch sie diese Methode zur Namensauflösung. Der sog. »Knotentyp« wird gesteuert von zwei Einträgen, »DhcpNodeType« und »NodeType«.

738

NetBT – NetBIOS over TCP/IP

Der »Knoten-Typ« (»node type«) eines NetBT-Rechners wird gesteuert bzw. vorgegeben von zwei Einträgen, nämlich »DhcpNodeType« und »NodeType«. Der Eintrag »DhcpNodeType« wird durch DHCP verwaltet, der Eintrag »NodeType« durch den Anwender bzw. Administrator. Ist der Eintrag »NodeType« vorhanden und ist der darin enthaltene Wert gültig, geht er dem Eintrag »DhcpNodeType« vor. Die vom DHCP-Server zugewiesenen Werte können also durch die lokale Registry-Eingabe zu »NodeType« übergangen bzw. außer Kraft gesetzt werden. Wert

Knoten-Typ

Methode

1

B-Node

Broadcasts

2

P-Node

Punkt-zu-Punkt-Anfrage an den/die WINS-Server

4

M-Node

Mixed Mode: Erst Broadcasts, dann Anfrage an den/die WINS-Server

8

H-Node

Hybrid Mode: Erst Anfrage an den/die WINS-Server, dann Broadcasts

Tab. A.111: NodeType-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

RandomAdapter REG_DWORD 0 | 1 Default: 0

Dieser Eintrag legt fest, ob NetBT über einen bestimmten oder wahlweise über einen von mehreren Adaptern arbeitet. Beträgt der Wert »1« (wahr / »true«), wählt NetBT mit einem Zufallsmechanismus die IP-Adresse, mit der alle Anfragen beantwortet werden, die über jeglichen der Adapter eintreffen, auf die NetBT gebunden ist. Typischerweise enthält jede Antwort als Absenderadresse die IP-Adresse des Adapters, über den die Anfrage einging. Die Verwendung des Zufallsmechanismus’ hat den Zweck, die Datenlast der Antwortpakete über alle vorhandenen Adapter gleichmäßig zu verteilen, sofern diese Adapter an dasselbe Netzwerk angeschlossen sind. Der Wert dieses Eintrags ist ohne Wirkung, wenn nicht der Wert von »SingleResponse« auf »1« (wahr / »true«) gesetzt ist. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: SingleResponse

Anhang A • Die Registry von Windows NT

739

RefreshOpCode REG_DWORD 8 | 9 Default: 8

Dieser Eintrag legt den »Operation Code« fest, der in »Name Refresh«-Paketen eingetragen wird, wenn die NetBIOS-Namensanmeldung erneuert wird. Die Spezifikation des NetBT-Protokolls ist nicht völlig eindeutig. Obwohl der Vorgabewert »8« (benutzt von Microsoft) der beabsichtigte Wert zu sein scheint, verwenden einige andere Umsetzungen (z.B. von Ungermann-Bass) den Wert »9«. Um aber zueinander kompatibel zu sein, müssen die beteiligten Rechner denselben »Operation Code« verwenden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

ScopeID REG_SZ * | DNS DOMAIN NAME (Sämtlich Großbuchstaben / darf nicht mit einem Punkt beginnen) Default: * (Asterisk)

Der Wert dieses Eintrages gibt die Reichweite bzw. Einschränkung der NetBIOSNamen an. Ist der Wert * , so ist kein eigentlicher Wert gesetzt, alle Namen können angefragt werden. Der sog. »Name Scope« (sozusagen die »Sichtweite«) wird von zwei anderen Einträgen gesteuert, »DhcpScopeId« und »ScopeId«, wobei »DhcpScopeId« von DHCP und »ScopeId« vom lokalen Anwender bzw. Administrator gesetzt wird. Wenn der Wert von »ScopeId« den * (Stern, Asterisk) enthält oder einen gültigen DNS-Namen, so geht dieser Wert dem von »DhcpScopeId« vor. Dieser Eintrag wird in der Registry erzeugt, wenn in der »Systemsteuerung\Netzwerk« TCP/IP konfiguriert wird. Um Änderungen an diesem Eintrag vorzunehmen, sollte die Systemsteuerung verwendet werden.

SessionKeepAlive REG_DWORD 0xEA60 (1 Minute)- 0xFFFFFFFE Millisekunden | 0xFFFFFFFF Default: 0x36EE80 (1 Stunde)

740

NetBT – NetBIOS over TCP/IP

Dieser Eintrag gibt das Intervall zwischen »Keep-Alive«-Übertragungen an, mit denen angezeigt wird, dass eine NetBIOS-Sitzung weiter aufrecht erhalten wird (darum auch bekannt als »Session-Alive«). NetBT sendet »Keep-Alive«-Meldungen, um sicherzustellen, dass eine ansonsten (zurzeit) ungenutzte Verbindung weiter aufrecht erhalten wird. So wird vermieden, dass aus Versehen Verbindungen abgebaut werden, die noch aufrecht zu erhalten sind. Wert

Bedeutung

0xEA60-0xFFFFFFFE Millisekunden

Der Wert gibt das Intervall zwischen »Keep-Alive«-Meldungen an.

0xFFFFFFFF

Es werden keine »Keep-Alive«-Meldungen gesendet.

Tab. A.112: SessionKeepAlive-Werte

SingleResponse REG_DWORD 0 | 1 Default: 0

Dieser Eintrag legt fest, ob bei Namensanfragen die Antworten an eine oder mehrere IP-Adressen (Adapter mit IP) zurückgegeben werden. Wenn die Funktion »RandomAdapter« verwendet wird, muss »SingleResponse« in die Registry eingefügt und auf »1« gesetzt werden. Wert

Bedeutung

0

NetBT bedient alle IP-Adressen sämtlicher Adapter, auf die NetBT gebunden ist.

1

NetBT bedient nur eine IP-Adresse aus der Zahl aller Adaper, auf die es gebunden ist.

Tab. A.113: SingleResponse-Werte

Dieser Wert verändert das Verhalten des NetBT Protokoll-Treibers nur bei »multihomed«, wenn der Rechner an mehrere IP-Netzwerke (IP-Subnetze) angeschlossen ist. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: RandomAdapter

Anhang A • Die Registry von Windows NT

741

Size [Small/Medium/Large] REG_DWORD 1 | 2 | 3 Default: 1 (klein=small) oder 3 (groß=large)

Dieser Eintrag gibt die Größe der Namens-Zugriffs-Tabelle an (»name cache hash table«). Diese Tabelle wird verwendet, um Maschinen-Namen (NetBIOS-Name) aufzunehmen. Meistens reicht der Wert »1« (klein=small). Arbeitet der Rechner als Proxy Name Server, wird der Wert automatisch auf »3« gesetzt, um die Größe der Tabelle zu erweitern. Die Größe der Tabelle wird in »Hash Buckets« angegeben. Wert

Bedeutung

1

Bis 16 Hash Buckets = »small«.

2

Bis 128 Hash Buckets = »medium«.

3

Bis 256 Hash Buckets = »large«.

Tab. A.114: Size-Werte [Small/Medium/Large]

TransportBindName REG_SZ String Default: \Device\

Dieser Eintrag dient allein der Produktentwicklung; sein Wert sollte nicht verändert werden.

WinsDownTimeout REG_DWORD 0x3E8 (1 Sekunde) – 0xFFFFFFFF Millisekunden Default: 0x3A98 (15 Sekunden)

Dieser Eintrag legt fest, wie lange NetBT wartet, bevor es versucht WINS zu verwenden, nachdem der Versuch fehl schlug, WINS-Server zu kontaktieren. Diese Funktion setzt Rechner, die zeitweise vom Netzwerk getrennt sind (etwa Laptops), in die Lage, zügig durch den Boot-Vorgang zu laufen, ohne etwa bei der WINS-Namensanmeldung (Registration) bis zum Erreichen der Zeitüberschreitung (Time-Out) warten zu müssen.

742

NetBT-Adapter-Parameter

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

A.20 NetBT-Adapter-Parameter HKEY_LM\System\CurrentControlSet\Services\NetBT\Adapters\AdapterName DhcpNameServer DhcpNameServerBackup NameServer NameServerBackup Tab. A.115: Registry-Schlüssel für NetBT Adapter Parameter

NetBT (NetBIOS over TCP/IP) Adapter Entries Diese Einträge werden für jeden Netzwerkadapter, über den NetBT arbeitet, einzeln angelegt und im jeweiligen Unterschlüssel des Adapters gespeichert. NetBT-Werte, die allgemein und für alle Adapter gelten, sind hinterlegt in den Parametern von »NetBT over TCP/IP«.

DhcpNameServer REG_SZ IP-Adresse Default: (Es gibt keinen Vorgabewert. Der Wert wird via DHCP vergeben.)

Dieser Eintrag enthält die IP-Adresse des primären WINS-Servers (Primary WINS Server). Der Wert wird von zwei Einträgen gesteuert: »DhcpNameServer« (vergeben über DHCP), und »NameServer« (vergeben vom Anwender). Wenn der Wert von »NameServer« gültig ist, geht er dem Wert von »DhcpNameServer« vor. Dieser Eintrag wird durch DHCP erzeugt und verändert, sofern der DHCP-Dienst eingeschaltet ist. Er sollte nicht manuell geändert werden.

DhcpNameServerBackup REG_SZ IP-Adresse Default: (Es gibt keinen Vorgabewert. Der Wert wird via DHCP vergeben.)

Anhang A • Die Registry von Windows NT

743

Dieser Eintrag enthält die IP-Adresse des Ersatz-WINS-Servers (Backup WINS Server / Secondary WINS Server). Der Wert wird von zwei Einträgen gesteuert: »DhcpNameServerBackup« (vergeben über DHCP), und »NameServerBackup« (vergeben vom Anwender). Wenn der Wert von »NameServerBackup« gültig ist, geht er dem Wert von »DhcpNameServerBackup« vor. Dieser Eintrag wird durch DHCP erzeugt und verändert, sofern der DHCP-Dienst eingeschaltet ist. Er sollte nicht manuell geändert werden.

NameServer REG_SZ IP-Adresse Default: (leerer Wert)

Dieser Eintrag enthält die IP-Adresse des primären WINS-Servers (Primary WINS Server). Der Wert wird von zwei Einträgen gesteuert: »DhcpNameServer« (vergeben über DHCP), und »NameServer« (vergeben vom Anwender). Wenn der Wert von »NameServer« gültig ist, geht er dem Wert von »DhcpNameServer« vor. Um diesen Wert zu verändern, sollte die Systemsteuerung verwendet werden, nicht aber ein Registry-Editor.

NameServerBackup REG_SZ IP-Adresse Default: (leerer Wert)

Dieser Eintrag enthält die IP-Adresse des Ersatz-WINS-Servers (Backup WINS Server / Secondary WINS Server). Der Wert wird von zwei Einträgen gesteuert: »DhcpNameServerBackup« (vergeben über DHCP), und »NameServerBackup« (vergeben vom Anwender). Wenn der Wert von »NameServerBackup« gültig ist, geht er dem Wert von »DhcpNameServerBackup« vor. Um diesen Wert zu verändern, sollte die Systemsteuerung verwendet werden, nicht aber ein Registry-Editor.

744

NetLogon

A.21 NetLogon HKEY_LM\System\CurrentControlSet\Services\Netlogon\Parameters ChangeLogSize MailslotDuplicateTimeout MaximumMailslotMessages MaximumMailslotTimeout Pulse PulseConcurrency PulseMaximum PulseTimeout1 PulseTimeout2 Randomize ReplicationGovernor Scripts Update Tab. A.116: Registry-Schlüssel für NetLogon

NetLogon Service Entries Der NetLogon\Parameters-Unterschlüssel speichert Einstellungen für den NetLogon-Dienst. Dieser repliziert die Datenbank des User Accounts Subsystem (UAS) zwischen Primary Domain Controller (PDC), Backup Domain Controller (BDC) und zugeordneten Servern, und prüft die Zulässigkeit von Logons in der jeweiligen, logischen Server-Domain. Der NetLogon-Freigabename sollte auch im Pfad für Logon-Scripts enthalten sein.

ChangeLogSize REG_DWORD 0x10000- 0x400000 bytes (64 Kbyte – 4 Mbyte) Default: 0x10000 (64 Kbyte)

Dieser Wert gibt die maximale Größe der Veränderungs-Protokoll-Datei an (»change log«). Diese Grenze betrifft sowohl die im physikalischen Hauptspeicher liegende Datei sowie auch die in Systemroot\Netlogin.chg gespeicherte Datei. Die typische Größe eines Eintrages beträgt 32 Bytes, was bei einer 64 Kbyte großen Log-Datei etwa 2.000 Einträgen entspricht. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

Anhang A • Die Registry von Windows NT

745

Eine Anhebung des Wertes von »ChangeLogSize« auf 4 Mbyte beeinträchtigt die Systemleistung nicht, sorgt aber dafür, dass nur die veränderten Anteile der Domain-Datenbank repliziert werden. Der Wert von »ChangeLogSize« sollte auf allen BDCs derselbe sein wie auf dem aktuellen PDC, damit beim Ausfall des aktuellen PDC und dem Wechsel eines der BDCs zum PDC dieser denselben Wert in »ChangeLogSize« aufweist wie der vormalige PDC.

MaximumMailslotMessages REG_DWORD 0x1 – 0xFFFFFFFF Mailslot-Nachrichten Default: 0x1F4 (500)

Dieser Wert gibt die Höchstzahl von Mailslot-Nachrichten an, die im NetLogonDienst in die Warteschlange gestellt werden. Der NetLogon-Dienst ist darauf ausgelegt, eingehende Mailslot-Nachrichten sofort zu bearbeiten, aber Nachrichten können sich ansammeln bzw. aufstauen, wenn der Server eine große Zahl von ihnen zu bearbeiten hat. Jede MailslotNachricht verbraucht etwa 1.500 Bytes im Non-Paged Memory Pool, bis die Bearbeitung einsetzt. Eine Verminderung dieses Wertes vermindert den Verbrauch durch NetLogon im Non-Paged Memory Pool. Jedoch sollte darauf geachtet werden, dass der Wert nicht zu niedrig angesetzt wird, weil NetLogon sonst möglicherweise wichtige eingehende MailSlot-Nachrichten zurückweisen muss bzw. nicht annehmen kann. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

MaximumMailslotTimeout REG_DWORD 0x5-0xFFFFFFFF Sekunden Default: 0xA (10)

Dieser Wert gibt das höchste annehmbare Lebensalter eingehender MailslotNachrichten an. Wenn NetLogon eingegangene Mailslot-Nachrichten zur Bearbeitung annimmt, werden diese verworfen, wenn ihr Empfang schon länger zurückliegt, als in »MaximumMailslotTimeout« hinterlegt ist. Dies erlaubt NetLogon, die aktuelle(re)n Mailslot-Nachrichten zu bearbeiten. Wenn der Wert von »MaximumMailslotTimeout« zu niedrig angesetzt wird, könnte es sein, dass Net-

746

NetLogon

Logon eingehende Mailslot-Nachrichten ignoriert. Im vorgesehenenen Idealfall erfolgt die Bearbeitung einer jeden Mailslot-Nachricht binnen eines Sekundenbruchteils. Der Wert von »MaximumMailslotTimeout« wird nur dann spürbare Auswirkungen haben, wenn der Windows NT Server überlastet ist. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

MailslotDuplicateTimeout REG_DWORD 0 | 1-5 Sekunden Default: 2

Dieser Wert gibt den Mindestzeitraum an, der zwischen zwei Mailslot-Nachrichten liegen muss, die von NetLogon empfangen werden. Gehen bei NetLogon zwei Mailslot-Nachrichten mit einem kürzeren oder gleichen zeitlichen Abstand ein, verglichen mit dem in »MailslotDuplicateTimeout« hinterlegten Wert, so wird die jeweils zweite Mailslot-Nachricht übergangen in der Annahme, es handele sich um ein Doppel der ersten Nachricht. Wert

Bedeutung

0

NEIN – NetLogon ignoriert keine Mailslot-Nachrichten, gleich, in welchem Abstand sie eintreffen.

1–5 Sek.

JA – NetLogon ignoriert Mailslot-Nachrichten, wenn ihr Zeitabstand kleiner als die angegebene Zeit ist.

Tab. A.117: MailslotDuplicateTimeout-Werte

Dieser Wert kann auf »0« gesetzt werden, wenn das Netzwerk so konfiguriert ist, dass diese Maschine bestimmte Mailslot-Nachrichten empfangen, aber nicht beantworten kann, etwa dann, wenn ein Domain Controller von einem WinNTClient durch eine Brücke oder einen Router getrennt ist. Weil die/der Bridge/Router hinausgehende NBF Broadcasts filtert, aber nicht hereinkommende Broadcasts, antwortet NetLogon auf NBF Mailslot-Nachrichten (die dann durch die/den Bridge/Router herausgefiltert werden), aber antwortet nicht auf Serien mehrerer Mailslot-Nachrichten. Dieses Problem kann behoben werden, indem diese Einstellung aufgehoben wird (oder indem die/der Bridge/Router anders eingestellt wird). Wird dieser Wert zu hoch angesetzt, ignoriert NetLogon Wiederholungen seitens der Clients.

Anhang A • Die Registry von Windows NT

747

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

Pulse REG_DWORD 60-172.800 Sekunden (Bis 48 Stunden) Default: 300 (5 Minuten)

Dieser Wert gibt die Dauer eines Pulses an. Alle SAM/LSA-Änderungen, die an einem Primary Domain Controller (PDC) innerhalb eines Pulses getätigt werden, werden gesammelt und zu jedem Backup Domain Controller (BDC) gesendet, der diese Änderungen benötigt. An BDCs, die auf dem letzten Stand sind, werden keine Pulse geschickt. NetLogon berechnet eine optimale Pulsdauer, ausgehend von der Arbeitsbelastung des PDC. Dieser selbst errechnete Wert kann übergangen werden, indem der Registry-Eintrag »Pulse« angelegt wird. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

PulseConcurrency REG_DWORD 1 bis 500 Pulse Default: 20

Dieser Wert gibt die maximale Anzahl gleichzeitiger Pulse an, die ein Primary Domain Controller (PDC) an Backup Domain Controller (BDC) sendet. Dieser Wert ist darauf ausgelegt, die Arbeitsbelastung zu begrenzen, die sich aus den Antworten ergibt, die nach Pulsesendungen beim PDC eintreffen. Der PDC muss schnell genug sein, alle diese gleichzeitigen Replikations-RPC-Rufe zu verarbeiten. Die Erhöhung des Wertes von »PulseConcurrency« erhöht die Last des PDCs; eine Verminderung dieses Wertes erhöht die Zeit, die es in einer Domain braucht, bis eine große Zahl von BDCs vollständig mit den Replikationen von SAM/LSA-Änderungen auf den neuesten Stand gebracht wurde. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: PulseConcurrency

748

NetLogon

PulseMaximum REG_DWORD 60-172,800 Sekunden (Bis 48 Stunden) Default: 7.200 (2 Stunden)

Dieser Wert gibt die maximale Zeit zwischen zwei Pulsen an. Wenn die Zeit, die mit »PulseMaximum« beziffert ist, abgelaufen ist, sendet der Primary Domain Controller (PDC) mindestens einen Puls, auch dann, wenn alle Backup Domain Controller (BDC) mit ihren Datenbanken auf dem neuesten Stand sind. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

PulseTimeout1 REG_DWORD 1-120 Sekunden Default: 5

Dieser Wert gibt an, wie lange ein Primary Domain Controller (PDC) wartet, bis eine Antwort von einem Backup Domain Controller (BDC) eintrifft. Läuft diese Zeit »PulseTimeout1« ohne Antwort des BDC ab, gilt dieser als nicht erreichbar oder »schweigsam« (»unresponsive«). Ein »unresponsive BDC« wird nicht mit dem Limit verrechnet, das in »PulseConcurrency« angegeben ist und das dem PDC erlaubt, Pulse zu einem anderen BDC in der Domain zu senden. Wenn dieser Wert zu hoch ist, benötigt eine Domain mit vielen »unresponsive BDCs« lange Zeit, um eine Teilreplikation abzuschließen. Ist der Wert zu niedrig, kann dies dazu führen, dass ein langsamer BDC irrtümlich als »unresponsive« (ausgefallen, abwesend, verhindert) angesehen wird. Wenn ein BDC bis zur letzten Gelegenheit nicht geantwortet hat, wird er seinerseits versuchen sich beim PDC auf den letzten Stand zu bringen, was wiederum die Belastung des PDC ansteigen lässt. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: PulseConcurrency PulseTimeout2

Anhang A • Die Registry von Windows NT

749

PulseTimeout2 REG_DWORD 60-3600 Sekunden Default: 300 (5 Minuten)

Dieser Wert gibt an, wie lange ein Primary Domain Controller (PDC) wartet, bis ein Backup Domain Controller (BDC) jeden einzelnen Schritt im Replikationsvorgang abgeschlossen hat. Ist die Zeit, die in »PulseTimeout2« angegeben ist, verstrichen, sieht der PDC den BDC als »unresponsive« an (abwesend, verhindert), was ihm die Freiheit gibt, einen Puls an einen anderen BDC in der Domain zu senden. »PulseTimeout2« gilt nur für PDCs und wird nur verwendet, wenn ein BDC nicht alle Änderungen in der SAM/LSA-Datenbank in einem einzigen RPCRuf beziehen kann. Ist ein BDC in der Lage zu antworten (oder wird dies von ihm erwartet), so hat er auf den Puls zu antworten und fortlaufend über seine Fortschritte in der Replikation zu antworten. Wenn die Intervalle dieser Fortschrittsmeldungen den Wert von »PulseTimeout2« überschreiten, gilt der BDC als »unresponsive«. Ein »unresponsive BDC« wird nicht mit dem Limit verrechnet, das in »PulseConcurrency« angegeben ist und das dem PDC erlaubt, Pulse zu einem anderen BDC in der Domain zu senden. Ist der Wert zu hoch, verbraucht ein langsamer BDC (oder ein BDC, dessen Replikationsrate zu gering ist) einen »PulseConcurrency«-Zeitschlitz. Ist der Wert zu gering, steigt die Arbeitslast des PDC wegen der steigenden Zahl von BDCs, die Teilreplikationen verarbeiten bzw. vornehmen. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Siehe auch: PulseConcurrency PulseTimeout1

Randomize REG_DWORD 0-120 Sekunden Default: 1

Dieser Wert gibt an, wie lange ein Backup Domain Controller (BDC) nach Erhalt eines Pulses wartet, bevor er an den Primary Domain Controller (PDC) antwortet. Der Wert von »Randomize« muss kleiner sein als der von »PulseTimeout1«, da sonst der PDC den BDC als »unresponsive« ansieht (ausgefallen, verhindert).

750

NetLogon

Um einen optimalen Wert für »Randomize« zu berechnen, muss beachtet werden, dass die erforderliche Zeit zur Replikation der SAM/LSA-Änderungen bzw. zur Versendung an alls BDCs in der Domain größer sein soll als: [(Randomize/2) * NumberOfBDCsInDomain] / PulseConcurrency

Wenn der Wert »Randomize« in der Registry nicht eingetragen ist, errechnet NetLogon selber einen optimalen Wert in Abhängigkeit zur Arbeitslast des PDC. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software.

ReplicationGovernor REG_DWORD 0-100 Prozent Default: 100

Dieser Wert gibt das Verhältnis an zwischen der Datenmenge, die mit jedem Ruf an den Primary Domain Controller (PDC) verschickt wird, und der Häufigkeit dieser Rufe. Beispiel: Wenn der Wert von »ReplicationGovernor« 50 beträgt, wird eher ein 64Kbyte-Puffer übertragen als ein 128-Kbyte-Puffer, und ein Replikationsruf kann im Netzwerk ausstehen für nicht mehr als 50 % der angegebenen Zeit. Wenn der Wert von »ReplicationGovernor« 0 ist, nimmt NetLogon keine Replikationen vor und die SAM/LSA-Datenbanken werden nicht repliziert bzw. abgeglichen. Ist der Wert von »ReplicationGovernor« zu gering, kann das dazu führen, dass die Replikationen nicht vollendet bzw. abgeschlossen werden können. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige, geeignete Software. Es können unterschiedliche Replikationsraten für verschiedene Zeitpunkte am Tag angegeben werden unter Verwendung von REGINI.EXE, dieses Programm ist im »Windows NT Server Resource Kit 4.0« enthalten, sowie mit dem »AT«Programm, das bereits mit Windows-NT ausgeliefert wird. Die REGINI-Scripts müssen so bearbeitet werden, dass der Wert für »ReplicationGovernor« entsprechend gesetzt wird; dann soll »AT« verwendet werden um das REGINI-Script auszuführen, um die Änderungen in Kraft zu setzen.

Anhang A • Die Registry von Windows NT

751

Scripts REG_SZ Path Default: (Für diesen Eintrag gibt es keinen Vorgabewert.)

Dieser Wert gibt den vollen Pfad des Logon-Scripts an (»fully qualified path to logon scripts«). Um den Wert von »Scripts« zu ändern, wird der Punkt »Services« in der Systemsteuerung oder im Server-Manager verwendet.

Update REG_SZ yes | no Default: no

Dieser Wert gibt an, ob NetLogon die Datenbank jedesmal beim Start vollständig synchronisiert. Wert

Bedeteung

yes

NetLogon synchronisiert die Datenbank beim Start vollständig.

no

NetLogon synchronisiert die Datenbank beim Start nicht vollständig.

Tab. A.118: Update-Werte

A.22 NwLnkIpx – NetWare Link IPX HKEY_LM\System\CurrentControlSet\Services\NwlnkIpx\NetConfig\Driver# AdapterName BindSap DefaultAutoDetectType EnableFuncaddr EnableWanRouter MaxPktSize NetworkNumber PktType SourceRouteBcast SourceRouteDef Tab. A.119: Registry-Schlüssel für NwLnkIpx – NetWare Link IPX

752

NwLnkIpx – NetWare Link IPX

HKEY_LM\System\CurrentControlSet\Services\NwlnkIpx\NetConfig\Driver# SourceRouteMcast SourceRouting Tab. A.119: Registry-Schlüssel für NwLnkIpx – NetWare Link IPX (Forts.)

NWLink Entries for IPX/SPX for the Network Adapter Card Die in diesem Abschnitt beschriebenen Werteeinträge steuern die Protokollbindung von NWLink an den Netzwerkadapter. Die Vorgabewerte können je nach Netzwerkadapter und Hersteller unterschiedlich sein. In Windows NT 3.1 erscheinen diese Einträge im Unterschlüssel NWLinkIPX\ NetConfig\Driver#.

AdapterName REG_DWORD

Name

Dieser Wert gibt den Namen des Netzwerkadapters an, den NWLink verwendet. Der Wert kann in der Systemsteuerung verändert werden durch Anwahl des Netzwerkadapters und Bindung von NWLink an den Adapter.

BindSap REG_DWORD Ethertype Default: 0x1FC9 (8137)

Dieser Wert gibt den EtherType an, falls Ethernet II als Frame-Format verwendet wird; ist dieses nicht der Fall, wird dieser Registry-Eintrag nicht verwendet. Änderungen werden über die Systemsteuerung vorgenommen. Siehe auch: PktType

DefaultAutoDetectType REG_DWORD 0 | 1 | 2 | 3 | 4 Default: 2

Anhang A • Die Registry von Windows NT

753

Dieser Wert gibt den Pakettyp an, den IPX verwendet, wenn nicht sofort beim Start irgendwelche Server gefunden werden konnten. Wenn ein neuer Pakettyp erkannt wird, passt der Transporttreiber den Wert automatisch an. Wert

Bedeutung

0

Ethernet_II

1

Ethernet_802.3

2

802.2

3

SNAP

4

ARCnet

Tab. A.120: DefaultAutoDetectType-Werte

EnableFuncaddr REG_DWORD 0 | 1 Default: 1

Dieser Wert bestimmt, ob als MAC-Adresse bei Broadcasts die IPX-Funktionsadresse verwendet werden soll. Dieser Wert arbeitet nur bei Token-Ring Adaptern. Wert

Bedeutung / verwendete MAC Broadcast Adresse

0

0xFFFFFFFFFFFF / entspricht der Standardadresse

1

0xC00000800000. / IPX Funktionsadresse

Tab. A.121: EnableFuncaddr-Werte

EnableWanRouter REG_DWORD 0 | 1 Default: 1

Dieser Wert bestimmt, ob der aktuelle Netzwerkadapter das Routing Information Protocol (RIP) verwendet. Wert

Bedeutung

0

NEIN – Der aktuelle Adapter verwendet RIP nicht.

1

JA – Der aktuelle Adapter verwendet RIP.

Tab. A.122: EnableWanRouter-Werte

754

NwLnkIpx – NetWare Link IPX

MaxPktSize REG_DWORD 0 | 1-65.535 Bytes Default: 0

Dieser Wert bestimmt die größte mögliche Paketgröße, die der Netzwerkadapter verwenden darf. NWLink fragt beim Netzwerkadapter die maximale Paketgröße ab und stellt sich entsprechend ein; wird aber mit einer Gegenstelle kommuniziert, die mit kleineren Paketgrößen arbeitet, kann es hilfreich sein, den Wert von »MaxPktSize« entsprechend zu vermindern. Wert

Bedeutung

0

NWLink übernimmt die maximale Paketgröße vom Netzwerkadapter.

1 – 65535

NWLink arbeitet mit dem angegebenen Wert.

Tab. A.123: MaxPktSize-Werte

NetworkNumber REG_DWORD 0x0 | 0x1 – 0xFFFFFFFF Default: 0x0

Dieser Wert bestimmt die IPX Netzwerknummer des Netzwerkadapters. IPX Netzwerknummern sind 4 Bytes lang; das entspricht acht Zeichen in HexSchreibweise und werden ansonsten von NWLink gesetzt. Wert

Bedeutung

0x0

NWLink übernimmt die IPX Netzwerknummer aus dem gegebenen Netzwerk.

0x1 – 0xFFFFFFFF

NWLink übernimmt die hier gesetzte Netzwerknummer.

Tab. A.124: NetworkNumber-Werte

Änderungen werden über die Systemsteuerung vorgenommen.

PktType REG_DWORD 0 | 1 | 2 | 3 | 4 Default: 1 (Ethernet_802.3)

Anhang A • Die Registry von Windows NT

755

Dieser Wert gibt den Frame-Typ an, der vom NWLink-Dienst verwendet werden soll. Wert

Bedeutung

0

Ethernet_II

1

Ethernet_802.3

2

802.2

3

SNAP

4

Arcnet

Tab. A.125: PktType-Werte

Siehe auch: BindSap

SourceRouteBcast REG_DWORD 0 | 1 Default: 0

Dieser Wert gibt an, welcher Broadcast-Typ (ARB oder SRB) bei Token-Ring Source-Routing verwendet wird, wenn ein Paket an die MAC Broadcast-Adresse 0xFFFFFFFFFFFF gesendet wird. Wert

Bedeutung

0

Das Paket wird an die Single-Route Broadcast (SRB) Adresse übergeben (0xC2, 0x70).

1

Das Paket wird an die All-Routes Broadcast (ARB) Adresse übergeben (0x82, 0x70).

Tab. A.126: SourceRouteBcast-Werte

Siehe auch: SourceRouteDef SourceRouting SourceRouteMCast

SourceRouteDef REG_DWORD 0 | 1 Default: 0

756

NwLnkIpx – NetWare Link IPX

Dieser Wert gibt an, welcher Broadcast-Typ (ARB oder SRB) bei Token-Ring Source-Routing verwendet wird, wenn ein Paket an eine eindeutige, individuelle MAC-Adresse gesendet werden soll und diese noch nicht in der Source-RouteTabelle steht. Wenn eine MAC-Adresse bereits in der Source-Route-Tabelle steht, wird der dort angegebene Weg verwendet. Wert

Bedeutung

0

Das Paket wird an die Single-Route Broadcast (SRB) Adresse übergeben (0xC2, 0x70).

1

Das Paket wird an die All-Routes Broadcast (ARB) Adresse übergeben (0x82, 0x70).

Tab. A.127: SourceRouteDef-Werte

Siehe auch: SourceRouteBcast SourceRouting SourceRouteMCast

SourceRouteMcast REG_DWORD 0 | 1 Default: 0

Dieser Wert gibt an, welcher Broadcast-Typ (ARB oder SRB) bei Token-Ring Source-Routing verwendet wird, wenn ein Paket an eine MAC Multicast-Adresse gesendet werden soll (0xC000xxxxxxxx). Wert

Bedeutung

0

Das Paket wird an die Single-Route Broadcast (SRB) Adresse übergeben (0xC2, 0x70).

1

Das Paket wird an die All-Routes Broadcast (ARB) Adresse übergeben (0x82, 0x70).

Tab. A.128: SourceRouteMcast-Werte

Siehe auch: SourceRouteBcast SourceRouteDef SourceRouting

Anhang A • Die Registry von Windows NT

757

SourceRouting REG_DWORD 0 | 1 Default: 1

Dieser Wert gibt an, ob der NWLink-Dienst Source-Routing verwendet. Dieser Eintrag hat nur bei Token-Ring Bedeutung. Wert

Bedeutung

0

NEIN – Es wird kein Source-Routing verwendet (Token-Ring ohne SourceRoute Bridges).

1

JA – Es wird Source-Routing verwendet (nur bei Token-Ring).

Tab. A.129: SourceRouting-Werte

Siehe auch: SourceRouteBcast SourceRouteDef SourceRouteMCast

A.23 NwlnkNb – Novell NetBIOS HKEY_LM\System\CurrentControlSet\Services\NwlnkNb\Parameters AckDelayTime AckWindow AckWindowThreshold EnablePiggyBackAck Extensions RcvWindowMax Tab. A.130: Registry-Schlüssel für NwLnkNB – NetWare NetBIOS

NwlnkNb-Einträge für die Microsoft-Erweiterungen zu Novell-NetBIOS Der Registry-Unterschlüssel »NwlnkNb\Parameters« (Windows NT 3.1: »NWNBLink\Parameters«) enthält Steuerdaten für die Erweiterungen, die Microsoft am Novell-NetBIOS vorgenommen hat. Die Erweiterungen dienen einer verbesserten Funktionsweise des Novell-NetBIOS Protokolls. Dieser Registry-Unterschlüssel erscheint bei WinNT 3.1 als NWNBLink-Unterschlüssel.

758

NwlnkNb – Novell NetBIOS

AckDelayTime REG_DWORD 50-65,535 Millisekunden Default: 250

Dieser Wert gibt einen Zeitwert an für verzögert gesendete Empfangsbestätigungen (»Acknowledgment«, ACK).

AckWindow REG_DWORD 0 | 1 – 65,535 frames Default: 2

Dieser Wert gibt die Zahl zu empfangender Pakete an, bevor eine Quittung (ACK) gesendet wird. Die Menge der empfangenen Bytes, die damit indirekt beschrieben wird, wird als Empfangsfenster bzw. »Window« bezeichnet; entsprechend heißt dieser Parameter »AckWindow«. Wert

Bedeutung

0

Es werden keine ACKs gesendet. Dieser Wert ist angemessen, wenn Sender und Empfänger eine schnelle Verbindung haben.

1 – 65535

Der Wert gibt die Zahl der empfangenen Pakete an, nach deren Erhalt ein ACK gesendet werden muss.

Tab. A.131: AckWindow-Werte

Der Eintrag »AckWindow« dient der Regulation der Zahl der ACKs, wenn ein Sender mit schneller Anbindung mit einem Empfänger kommuniziert, der eine langsame Verbindung nutzt. Das Erzwingen von ACKs führt dazu, dass der Sender seine Pakete kontinuierlich(er) abgibt. Falls die Antwortzeit der Dialoge (hin/zurück) den Wert von »AckWindowThreshold« übertrifft, wird der Wert von »AckWindow« übergangen und das System bestimmt selber, ob bzw. wann ACKs gesendet werden sollen.

AckWindowThreshold REG_DWORD 0 | 1-65.535 Millisekunden Default: 500

Anhang A • Die Registry von Windows NT

759

Dieser Wert gibt die höchste erwartete Antwortzeit an, die zwischen Sendung eines Paketes und Eintreffen der Antwort verstreichen darf. NWNBLink benutzt diesen Wert, um zu bestimmen, ob es nötig ist, automatisch ACKs zu senden. Wert

Bedeutung

0

Es wird kein Maximum für die Antwortzeit bestimmt. Es werden automatisch ACKs gesendet, wann immer die Zahl der empfangenen Pakete den in »AckWindow« angegebenen Wert übersteigt.

1 – 65535

Maximale Antwortzeit in Millisekunden.

Tab. A.132: AckWindowThreshold-Werte

EnablePiggyBackAck REG_DWORD 0 | 1 Default: 1

Dieser Wert gibt an, ob dem Empfänger gestattet ist, »Piggyback«-ACKs zu senden. Diese Art von ACKs kann auftreten, wenn der Empfänger erkannt hat, dass das Ende einer NetBIOS-Nachricht erreicht ist. Wert

Bedeutung

0

NEIN – Der Empfänger verwendet keine Piggyback-ACKs.

1

JA – Der Empfänger darf Piggyback-ACKs versenden.

Tab. A.133: EnablePiggyBackAck-Werte

Wenn Sender und Empfänger verbindungsloses NetBIOS verwenden, sollte der Wert von »EnablePiggyBackAck« auf »0« gesetzt werden. Ein Beispiel: Ein Server sendet NetBIOS-Nachrichten, die durch den Client nicht bestätigt werden (verbindungslose Übertragung). Wenn der Wert von »EnablePiggyBackAck« auf »1« gesetzt ist und der Client Daten empfängt, aber nicht selber Daten sendet, wartet NWNBLink darauf, dass die in »AckDelayTime« angegebene Antwortzeit verstreicht, bevor das nächste ACK gesendet wird; sodann wird der Wert von »EnablePiggyBackAck« auf »0« gesetzt, wodurch die Piggiback-ACKs ausgeschaltet werden. Beginnt der Client daraufhin, selber Daten zu senden, setzt NWNBLink den Wert von »EnablePiggyBackAck« auf »1«.

760

Streams

Extensions REG_DWORD 0 | 1 Default: 1

Dieser Wert gibt an, ob die Microsoft-Erweiterungen zum Novell-NetBIOS verwendet werden (oder nicht). Wert

Bedeutung

0

NEIN – Die Microsoft Extensions werden nicht verwendet.

1

JA – Die Microsoft Extensions werden verwendet.

Tab. A.134: Extensions-Werte

RcvWindowMax REG_DWORD 1-49.152 Pakete Default: 4

Dieser Wert gibt die maximale Anzahl von Paketen an, die der Empfänger an einem Stück empfangen kann. Der in »RcvWindowMax« gesetzte Wert wird zu Beginn der Verbindung beim Handshake der Gegenstelle bekannt gegeben, was zu einer Beschränkung der Datenmenge führt, die seitens der Gegenstelle bis zum Eintreffen des nächsten ACK in einer Folge gesendet werden kann. Siehe auch: AckDelayTime AckWindow AckWindowThreshold EnablePiggyBackAck

A.24 Streams HKEY_LM\System\CurrentControlSet\Services\Streams\Parameters MaxMemoryUsage Tab. A.135: Registry-Schlüssel für NetRules

Streams Parameters for TCP/IP

Anhang A • Die Registry von Windows NT

761

MaxMemoryUsage REG_DWORD 0x0 – 0xFFFFFFFE bytes | 0xFFFFFFFF Default: 0xFFFFFFFF

Dieser Wert gibt die Höchstmenge an Speicher an, der von der Streams-Umgebung belegt werden kann. Wenn der Wert ausgeschöpft ist, schlagen weitere Versuche von Streams fehl, Speicher zu belegen. Wert (Bytes)

Bedeutung

0x0 – 0xFFFFFFFE

Der Höchstwert an Speicher, den Streams belegen kann.

0xFFFFFFFF

Es gibt keine Begrenzung in der Speichermenge, die Streams belegen könnte.

Tab. A.136: MaxMemoryUsage-Werte

A.25 TCP/IP-Parameter HKEY_LM\System\CurrentControlSet\Services\Tcpip\Parameters ArpAlwaysSourceRoute ArpCacheLife ArpTRSingleRoute ArpUseEtherSNAP DatabasePath DefaultTOS DefaultTTL DhcpNameServer Domain EnableDeadGWDetect EnablePMTUBHDetect EnablePMTUDiscovery EnableSecurityFilters ForwardBroadcasts ForwardBufferMemory Hostname IGMPLevel IPEnableRouter KeepAliveInterval KeepAliveTime MaxForwardBufferMemory MaxNumForwardPackets Tab. A.137: Registry-Schlüssel für TCP/IP

762

TCP/IP-Parameter

HKEY_LM\System\CurrentControlSet\Services\Tcpip\Parameters MaxUserPort NameServer NumForwardPackets PPTPTcpMaxDataRetransmissions SearchList TcpMaxConnectResponseRetransmissions TcpMaxConnectRetransmissions TcpMaxDataRetransmissions TcpNumConnections TcpTimedWaitDelay TcpUseRFC1122UrgentPointer TcpWindowSize Tab. A.137: Registry-Schlüssel für TCP/IP (Forts.)

TCPIP\Parameters Subkey Entries

ArpAlwaysSourceRoute REG_DWORD 0 | 1 Default: 0

Dieser Wert bestimmt, ob IP-Broadcasts über Source-Routing geschickt werden. WinNT-Rechner setzen bei IP-Paketen grundsätzlich das Source-Routing Bit. Transparent Bridges Pakete können bei einem Medienwechsel von Token-Ring etwa zu Ethernet den Source-Route-Anteil nicht weitergeben. Diese Anwendung von »ArpAlwaysSourceRoute« gilt ab WinNT 4.0 Service Pack 2. Auf älteren WinNT-Rechnern wird der Wert wie folgt verwendet: Wert

Bedeutung

0

Der Treiber sendet zuerst ARP-Requests ohne Source-Routing; wenn keine Antwort eintrifft, wird ein neuer Versuch mit Source-Routig unternommen.

1

TCP/IP ist gezwungen alle ARP-Requests mit Source-Routing zu senden.

Tab. A.138: ArpAlwaysSourceRoute-Werte bis WinNT4 SP1

Ab Windows NT 4.0 mit Service Pack 2 wird der Wert wie folgt verwendet: Wenn der Eintrag in der Registy nicht vorhanden ist, sendet der Treiber zunächst ARP-Requests ohne Source-Routing; kommt keine Antwort, wird die Wiederholung mit Source-Routing gesendet.

Anhang A • Die Registry von Windows NT

763

Ansonsten gilt darüber hinaus. Wert

Bedeutung

0

IP-Broadcasts werden OHNE Source-Routing gesendet.

1

IP-Broadcasts werden MIT Source-Routing gesendet.

Tab. A.139: ArpAlwaysSourceRoute-Werte ab WinNT4 SP2

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

ArpCacheLife REG_DWORD 0x0 – 0xFFFFFFFF Sekunden Default: 0x0258 (600 Sekunden = 10 Minuten) für benutzte Einträge; 0x0078 (120 Sekunden = 2 Minuten) für ungenutzte Einträge.

Dieser Wert gibt an, wie lange Einträge in der Tabelle des ARP Cache verbleiben. Derselbe Wert wird verwendet, um die Zahl sowohl der benutzten wie der unbenutzten Einträge zu begrenzen. Einträge in der Tabelle des ARP Cache verbleiben, bis die in »ArpCacheLife« gesetzte Zeit abgelaufen oder ein neuer Eintrag den Platz in der Tabelle braucht. Dieser Wert wird erst ab WinNT 3.51, Service Pack 4 (oder später) unterstützt. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor, oder über sonstige Software.

ArpTRSingleRoute REG_DWORD 0 | 1 Default: 0

Dieser Wert gibt an ob auf Token-Ring ARP-Broadcasts im Falle von SourceRouting als All-Routes Broadcasts (ARB) oder Single-Route Broadcasts (SRB) gesendet werden. Dieser Eintrag gilt nur, wenn Source-Routing verwendet wird.

764

TCP/IP-Parameter

Wert

Bedeutung

0

ARP-Broadcasts werden als ARB gesendet.

1

ARP-Broadcasts werden als SRB gesendet.

Tab. A.140: ArpTRSingleRoute-Werte

Dieser Wert wird erst ab WinNT 3.51, Service Pack 5 (oder später) unterstützt. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

ArpUseEtherSNAP REG_DWORD 0 | 1 Default: 0

Dieser Wert bestimmt, welches Ethernet Frame-Format von TCP/IP verwendet wird. Wert

Bedeutung

0

TCP/IP über Ethernet II / DIX.

1

TCP/IP über Ethernet nach IEEE 802.3 mit 802.2 LLC-SNAP.

Tab. A.141: ArpUseEtherSNAP-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

DatabasePath REG_EXPAND_SZ Path Default: Systemroot\System32\Drivers\Etc

Dieser Wert gibt den Pfad an zu den üblichen Internet Datenbank-Dateien wie Hosts.sam, Lmhosts.sam, Services.sm, Networks, Protocol und Quotes. Dieser Eintrag wird von der Windows-Sockets-Schnittstelle verwendet. Dieser Eintrag wird erzeugt, wenn in der Systemsteuerung TCP/IP konfiguriert wird.

Anhang A • Die Registry von Windows NT

765

DefaultTOS REG_DWORD 0-255 Default: 0

Dieser Eintrag legt den vorgegebenen Wert für den »Type of Service« (ToS) von IP fest. Die Verwendung von IP-ToS sowie die verschiedenen Werte sind im RFC 791 niedergelegt. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

DefaultTTL REG_DWORD 1-255 Sekunden Default: 128 (WinNT4), 32 (WinNT 3.51)

Dieser Eintrag enthält den Vorgabewert für den Parameter »Time To Live« (TTL) von IP. Der TTL-Wert stellt einen sog. Hop Credit dar, der die Zahl der RouterQuerungen und damit die Lebenszeit eines jeden IP-Pakets begrenzt. Jedes IPPaket wird vom Absender mit einem TTL-Guthaben ausgestattet; jeder Router vermindert den TTL-Wert; fällt TTL auf Null, so wird das IP-Paket verworfen. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

DhcpNameServer REG_SZ IPAddress[ IPAddress…] Default: (leerer Wert)

Dieser Eintrag speichert eine Liste von IP-Adressen von DNS-Servern, an die seitens der Windows Sockets die Anforderungen auf Namens- und Adressauflösung gerichtet werden. Dieser Registry-Eintag wird von zwei anderen Einträgen gesteuert, »DhcpNameServer« (wird von DHCP konfiguriert) und »NameServer« (kann frei konfiguriert werden). Besteht der Wert von »NameServer« aus einer oder mehreren IP-Adressen, gehen diese dem Eintrag von »DhcpNameServer« vor.

766

TCP/IP-Parameter

Dieser Eintrag wird erzeugt durch den DHCP Client-Dienst, sofern er eingeschaltet ist. Der Wert dieses Eintrages sollte nicht geändert werden.

Domain REG_SZ Domain Name Default: (Es gibt keinen Vorgabewert für diesen Eintrag. Über die Systemsteuerung muss bei der Konfiguration von TCP/IP ein gültiger Name eingetragen werden.)

Dieser Wert gibt den Domain-Namen des Rechners an, der von DNS verwendet wird. Dieser Wert wird von der Windows-Sockets-Schnittstelle verwendet. Dieser Eintrag wird erzeugt, wenn in der Systemsteuerung TCP/IP konfiguriert wird.

EnableDeadGWDetect REG_DWORD 0 | 1 Default: 1

Dieser Wert legt fest, ob TCP selbstständig die Erkennung toter Router betreibt: »dead gateway detection«. Diese Erkennung arbeitet wie folgt: Wenn TCP dasselbe TCP-Segment in mehrfachen Wiederholungen via Router gesendet hat, ohne Antworten zu erhalten, wird IP aufgefordert, über einen anderen Router zu arbeiten. Wert

Bedeutung

0

AUS: Keine »dead gateway detection«

1

EIN: Mit »dead gateway detection«

Tab. A.142: EnableDeadGWDetect-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. Um andere Router (Backup Router) zu definieren, ist in der Systemsteuerung unter TCP/IP das Feld »Eigenschaften« anzuwählen.

Anhang A • Die Registry von Windows NT

767

Siehe auch: EnablePMTUBHDetect EnablePMTUDiscovery

EnablePMTUBHDetect REG_DWORD 0 | 1 Default: 0

Dieser Wert bestimmt, ob TCP versucht sog. »Black Hole Router« zu erkennen, während die sog. Maximum Transmission Unit (MTU) ermittelt werden soll, die im Übertragungsweg (»Path«) unterstützt wird. Es geht darum, das IP Fragmenting zu vermeiden, weil Paketverluste die Folge sein könnten. Das Einschalten von »EnablePMTUBHDetect« hat zu Folge, dass die Zahl der Paketwiederholungen (bezogen auf dasselbe TCP-Segment) erhöht wird. Wert

Bedeutung

0

AUS – Die »Black Hole Detection« ist ausgeschaltet.

1

EIN – Die »Black Hole Detection« ist eingeschaltet.

Tab. A.143: EnablePMTUBHDetect-Werte

Wenn der Wert auf »1« gesetzt ist, erkennt TCP, dass dieselbe Datenmenge (TCP Segment) mehrfach übertragen wurde, ohne dass eine Antwort kam. Dieser Eintrag wurde mit WinNT 3.51 Service Pack 2 geändert. Bei WinNT 3.51 SP 1 (oder früher) hat TCP dasselbe Segment wiederholt gesendet, aber das »Don’t Fragment Bit« (DF) nicht gesetzt. Ab WinNT 3.51 SP 2 (oder später) vermindert TCP die »Maximum Segment Size« (MSS) auf 536 Bytes und setzt das »Don’t Fragment Bit« (DF). Wenn infolgedessen der Empfang des TCP-Segments von der Gegenstelle mit TCPACK bestätigt wurde, setzt TCP dieses Verfahren für diese Verbindung fort. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. Siehe auch: EnableDeadGWDetect EnablePMTUDiscovery

768

TCP/IP-Parameter

EnablePMTUDiscovery REG_DWORD 0 | 1 Default: 1

Dieser Wert legt fest, ob TCP eine fest eingestellte, vorgegebene »Maximum Transmission Unit« (MTU) verwendet, oder ob es versucht die aktuelle MTU zu ermitteln. Wert

Bedeutung

0

TCP verwendet eine MTU von 576 Bytes für alle Verbindungen zu Gegenstellen außerhalb des lokalen Subnets.

1

TCP versucht die MTU er ermitteln, die im Übermittlungsweg (Path) zur Gegenstelle verwendet werden kann.

Tab. A.144: EnablePMTUDiscovery-Werte

Durch die Ermittlung der »Path MTU« sowie der Beschränkung der TCP-Segmente auf eine entsprechende Größe kann TCP die IP-Fragmentierung der Pakete vermeiden. Wären die TCP/IP-Pakete zu groß für das physikalische Medium einer Transitstrecke, müssen Router die IP-Pakete jeweils in mehrere kleine aufteilen (IP Fragmenting). Die Fragmentierung von IP-Paketen kostet Durchsatz und erhöht die Staugefahr bei den Routern. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. Siehe auch: EnableDeadGWDetect EnablePMTUBHDetect

EnableSecurityFilters REG_DWORD 0 | 1 Default: 0

Dieser Wert bestimmt, ob der WinNT-Server UDP-Datagramme und TCP-SYNPakete filtert. Beträgt der Wert dieses Eintrages »1«, filtert der Server alle eingehenden UDP-Datagramme, alle rohen IP-Datagramme sowie alle TCP-SYNPakete. Das genaue Verhalten wird jeweils getrennt festgelegt je Schnittstelle gemäß den Werten für »UdpAllowedPorts«, »TcpAllowedPorts« und »RawIpAllowedProtocols«. Eingehende Pakete werden in der Transportschicht gefiltert (nicht durch IP). IP-Pakete, die per Routing an andere Rechner weitergeleitet werden, werden nicht gefiltert.

Anhang A • Die Registry von Windows NT

769

Dieser Wert wird erst ab WinNT 4.0 (oder später) unterstützt. Dieser Eintrag wird erzeugt, wenn in der Systemsteuerung TCP/IP konfiguriert wird.

ForwardBroadcasts REG_DWORD

WinNT gibt keine Broadcasts beim Routing weiter. Dieser Eintrag wird von Windows 2000 nicht unterstützt. Er braucht nicht entfernt zu werden, wenn er auftaucht; er kann ignoriert werden.

ForwardBufferMemory REG_DWORD 0x0 – 0xFFFFFFFF Bytes (muss ein Vielfaches von 256 sein) Default: 0x12200 (74,240 Bytes; genug für fünfzig 1.480-Byte-Packets, gerundet auf ein Vielfaches von 256)

Dieser Wert legt die Größe des Puffers fest, den IP belegt um Paketdaten in die Router-Warteschlange zu legen. Wenn keine Puffer belegt wurden, wird dieser Eintrag ignoriert. Weil die Puffer in der Paket-Daten-Warteschlange jeweils 256 Bytes lang sind, muss der Wert dieses Eintrages ein Vielfaches von 256 sein. Wenn der Pufferplatz belegt ist, beginnt der Router Pakete zu verwerfen; dies geschieht zufällig und kann jedes Paket in der Warteschlange treffen. Wenn Pakete zu groß für den Puffer sind, werden mehrere Puffer verkettet. Der IP-Header ist hiervon nicht betroffen, da dieser getrennt gespeichert wird. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor, oder über sonstige Software.

Hostname REG_SZ DNS host name Default: (Name des DNS Sservers.)

Dieser Eintrag enthält den DNS-Namen des Rechners. Dieser Name wird bei DNS-Anfragen zurückgegeben.

770

TCP/IP-Parameter

Dieser Eintrag wird erzeugt, wenn in der Systemsteuerung TCP/IP konfiguriert wird.

IGMPLevel REG_DWORD 0 | 1 | 2 Default: 2

Dieser Eintrag legt das Ausmaß fest, mit dem das IP-Multicasting unterstützt wird (IGMP: Internet Group Management Protocol). Wert

Bedeutung

0

Keine Unterstützung für IP Multicasts.

1

IP-Multicasts können gesendet, nicht empfangen werden.

2

IP-Multicasts können gesendet und empfangen werden (IGMP-Teilnahme).

Tab. A.145: IGMPLevel-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

IPEnableRouter REG_DWORD 0 | 1 Default: 0

Dieser Eintrag gibt an, ob der Rechner IP-Pakete in andere angeschlossene IPNetze routen kann. Wert

Bedeutung

1

JA – Der Rechner vermittelt IP-Pakete.

2

NEIN – Der Rechner vermittelt keine IP-Pakete.

Tab. A.146: IPEnableRouter-Werte

Dieser Eintrag wird erzeugt, wenn in der Systemsteuerung TCP/IP konfiguriert wird.

Anhang A • Die Registry von Windows NT

771

KeepAliveInterval REG_DWORD 0x1-0xFFFFFFFF Millisekunden Default: 0x3E8 (1 Sekunde)

Der Wert von »KeepAliveInterval« legt fest, wie oft TCP Keep-Alive-Übertragungen wiederholt, wenn keine Antwort kam. TCP sendet Keep-Alive-Mitteilungen, um der Gegenstelle mitzuteilen, dass die (zurzeit) ungenutzte Verbindung weiter aufrecht erhalten wird (werden soll). Dies schützt TCP-Verbindungen davor, unvorhergesehen beendet zu werden. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. Siehe auch: TcpMaxDataRetransmissions KeepAliveTime W3SVC\Parameters\AllowKeepAlives

KeepAliveTime REG_DWORD 0x1-0xFFFFFFFF Millisekunden Default: 0x6DDD00 (7.200.000 Millisekunden = 2 Stunden)

Der Wert von »KeepAliveTime« legt fest, wie oft TCP Keep-Alive-Mitteilungen sendet. Dieser Wert wird verwendet, wenn die Gegenstelle antwortet. Sollte dies nicht der Fall sein, wird der Abstand zwischen wiederholten Keep-Alive-Übertragungen durch den Wert von »KeepAliveInterval« bestimmt. Per Vorgabe werden keine Keep-Alive-Übertragungen durchgeführt. Die KeepAlive-Eigenschaft von TCP muss durch eine Applikation eingeschaltet werden; dies kann Telnet sein oder ein Internetbrowser. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor, oder über sonstige Software. Siehe auch: KeepAliveInterval W3SVC\Parameters\AllowKeepAlives

MaxForwardBufferMemory REG_DWORD

Network MTU-0xFFFFFFFF Bytes

772

TCP/IP-Parameter

Default: 0xFFFFFFFF

Der Wert dieses Eintrages legt die maximale Speichermenge fest, die IP zum Speichern in der Paketwarteschlange des Routers belegen kann. Dieser Wert muss größer als der (oder gleich dem) Wert in »ForwardBufferMemory« sein. Dieser Wert wird erst ab WinNT 3.51, Service Pack 2 (oder später) unterstützt. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

MaxNumForwardPackets REG_DWORD 0x1-0xFFFFFFFE | 0xFFFFFFFF Paket-Header Default: 0xFFFFFFFF

Der Wert dieses Eintrags legt die Zahl der IP-Paket-Header fest, die TCP in die Paketwarteschlange des Routers legen darf. Dieser Wert muss größer als der (oder gleich dem) Wert in »ForwardBufferMemory« sein. Wert

Bedeutung

0x1 – 0xFFFFFFFE

Der Wert bestimmt die maximale Zahl der IP Paket-Header, die in die Router-Warteschlange gelegt werden dürfen.

0xFFFFFFFF

Die Zahl der IP Paket-Header, die in die Router-Warteschlange gelegt werden dürfen, ist nicht begrenzt.

Tab. A.147: MaxNumForwardPackets-Werte

Dieser Wert wird erst ab WinNT 3.51, Service Pack 2 (oder später) unterstützt. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor, oder über sonstige Software.

MaxUserPort REG_DWORD 0x1388-0xFFFE (Port-Nummern 5000 – 65534) Default: 0x1388 (Port-Nummer 5000)

Anhang A • Die Registry von Windows NT

773

Dieser Eintrag legt die höchste TCP Port-Nummer fest, die von Applikationen belegt werden darf. Typischerweise werden für kurzzeitige Nutzungen die PortNummern zwischen 1.024 und 5.000 verwendet. Dieser Wert wird erst ab WinNT 3.51, Service Pack 5 (oder später) unterstützt. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

NameServer REG_SZ IPAddress[ IPAddress…] Default: (leerer Wert)

Dieser Eintrag enthält die IP-Adressen vom/von DNS-Server(n). Diese werden von den Windows Sockets angerufen, wenn Adress- und Namensauflösungen durchgeführt werden sollen. Wenn der (die) Wert(e) dieses Eintrages gültig ist, geht er dem Inhalt des Eintrags »DhcpNameServer« vor. Dieser Eintrag wird erzeugt, wenn in der Systemsteuerung TCP/IP konfiguriert ist.

NumForwardPackets REG_DWORD 0x1-0xFFFFFFFE Paket-Header Default: 0x32 (50)

Der Wert dieses Eintrages legt die anfängliche Zahl von IP Paket-Headern fest, die TCP in der Paketwarteschlange des Routers ablegen kann. Ist die Höchstzahl erreicht, beginnt der Router beliebige Pakete in der Warteschlange zu verwerfen. Dieser Eintrag wird nur verwendet, wenn das Routing eingeschaltet ist und IPHeader in den Speicher gelegt werden. Der Wert sollte höchstens so groß sein wie der von »ForwardBufferMemory«, geteilt durch die maximale IP-Datengröße des Netzwerks, an den der Rechner angeschlossen ist. Er sollte nicht größer sein als der Wert von »ForwardBufferMemory«, geteilt durch 256, da mindestens jeweils 256 Bytes von jedem IP-Paket belegt werden. Die optimale Anzahl der »Forward Packets« für einen bestimmten »ForwardBufferMemory« hängt ab von der Art des Datenverkehrs und liegt vermutlich zwischen den beiden beschriebenen Werten.

774

TCP/IP-Parameter

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. Siehe auch: MaxNumForwardPackets

PPTPTcpMaxDataRetransmissions REG_DWORD 0x0 – 0xFFFFFFFF Retransmissions (Wiederholungen) Default: 0x9

Dieser Eintrag legt fest, wie oft ein PPTP-Paket erneut gesendet wird, wenn es nicht von der Gegenstelle bestätigt wird. Um die »dead gateway detection« von TCP davor zu schützen, eine zwar verstopfte, aber sonst arbeitende Internetverbindung zu kappen, sollte der Wert größer sein als der Vorgabewert von »TCPMaxDataRetransmission«. Dieser Eintrag wird erst ab WinNT 4.0 (oder später) unterstützt. Dieser Eintrag wird erzeugt, wenn in der Systemsteuerung TCP/IP konfiguriert wird. Siehe auch: EnableDeadGWDetec

SearchList REG_SZ DNS Domain Name Suffix[ DNS Domain Name Suffix…] Default: (Der für die Domain gültige Wert)

Dieser Eintrag enthält eine Liste von »Domain Name Suffixes«; das sind Namensendungen von DNS-Domänen. Die hier hinterlegten Endungen werden verwendet, wenn Namensauflösungen ohne jeden Suffix per DNS nicht zum Erfolg führen. Dieser Wert wird von der Windows-Sockets-Schnittstelle verwendet. Dieser Eintrag wird erzeugt, wenn in der Systemsteuerung TCP/IP konfiguriert wird.

TcpMaxConnectResponseRetransmissions REG_DWORD 0 | 1 | 2 | 3 Default: 3

Anhang A • Die Registry von Windows NT

775

Dieser Eintrag legt fest, wie oft eine Erwiderung auf einen TCP-Verbindungsaufbau (bzw. auf den Versuch desselben) wiederholt wird. Anders gesagt: Dieser Wert legt fest, wie viele TCP-SYN-ACKs nach Eingang eines TCP-SYN gesendet werden. Die erste Verzögerung liegt bei drei Sekunden; mit jeder neuen Übertragung des TCP-SYN-ACKs wird diese Wartezeit verdoppelt. Der Zweck dieses Wertes bzw. der dahinter liegenden Funktion ist, WinNT-Rechner vor der Überflutung mit TCP-SYNs zu schützen (TCP-SYN Flooding). Wert

Wiederholungen nach n Sek.

Verstrichene Zeit

Ergebnis

0

Es werden keine SYN-ACKs in Wiederholung gesendet.

Nach drei Sekunden ist der TCPSYN-Versuch verfallen.

Dieser Wert kann dazu führen, dass korrekte Versuche des Verbindungsaufbaus scheitern, wenn die Laufzeit über ein langsames Netz hin und zurück mehr als drei Sekunden beträgt.

1

3 Sekunden

9 Sekunden

Der Versuch gilt nach sechs Sekunden nach der letzten Wiederholung als beendet.

2

3 und 6 Sekunden

21 Sekunden

Der Versuch gilt nach zwölf Sekunden nach der letzten Wiederholung als beendet.

3

3, 6, 12 Sekunden

45 Sekunden

Der Versuch gilt nach 24 Sekunden nach der letzten Wiederholung als beendet.

Tab. A.148: TcpMaxConnectResponseRetransmissions-Werte

Dieser Wert wird erst ab WinNT 4.0 Service Pack 2 (oder später) unterstützt (Tcpip.sys).

TcpMaxConnectRetransmissions REG_DWORD 0x0-0xFFFFFFFF Default: 0x3

Dieser Eintrag bestimmt, wie oft TCP den Versuch eines Verbindungsaufbaus wiederholt; anders gesagt: Dieser Wert begrenzt die Zahl der TCP-SYNs. Wird dieser Wert erreicht, gilt der Verbindungsaufbau als gescheitert. Der Versuch eines Verbindungsaufbaus gilt als unbeantwortet durch die Gegenstelle (und wird wiederholt), wenn die Wartezeit vom Retransmission Time-Out überschritten

776

TCP/IP-Parameter

wurde. Die anfängliche Wartezeit für die Wiederhlung eines TCP-SYN beträgt drei Sekunden. Mit jeder weiteren Wiederholung verdoppelt sich diese Wartezeit. Treffen Antworten ein, wird die Wartezeit zurückgesetzt. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

TcpMaxDataRetransmissions REG_DWORD 0x0-0xFFFFFFFF Default: 0x5

Dieser Wert legt die maximale Zahl von TCP-Retransmissions fest für ein und dasselbe Datensegment (non-connect segment), bevor die Verbindung verloren gegeben wird. Die Übertragung eines Datensegments (die Datenmenge, die in ein TCP-Paket passt und durch die Sequence Number gekennzeichnet ist) gilt als fehlgeschlagen (und wird wiederholt), wenn der Retransmission Time-Out abgelaufen ist. Der anfängliche Wert für den Retransmission Time-Out wird von TCP durch das Messen der mittleren Antwortzeit im Wechselspiel mit der Gegenstelle errechnet. Dieser Time-Out-Wert wird verdoppelt mit jeder Wiederholung innerhalb derselben TCP-Session; er wird wieder zurückgesetzt, wenn eine Antwort der Gegenstelle eintrifft. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

TcpNumConnections REG_DWORD 0x0-0xFFFFFE Default: 0xFFFFFE

Dieser Wert legt die Höchstzahl von TCP-Verbindungen fest, die gleichzeitig offen gehalten werden können (dürfen). Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

Anhang A • Die Registry von Windows NT

777

TcpTimedWaitDelay REG_DWORD 0x1E-0x12C Sekunden (30-300 Sekunden) Default: 0xF0 (240 Sekunden = 4 Minunten)

Dieser Eintrag legt fest, wie lange eine TCP-Verbindung im Status TIME_WAIT verbleibt (auch als »2MSL Status« bekannt), wenn sie geschlossen wurde. Solange der Status TIME_WAIT anhält, kann das Socket-Paar nicht erneut verwendet werden. RFC 793 gibt an, dass dieser Wert das Zweifache des Wertes betragen soll, den die maximale Lebenszeit von TCP-Segmenten im Netzwerk ausmacht. Dieser Wert wird erst ab WinNT 3.51, Service Pack 5 (oder später) unterstützt. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

TcpUseRFC1122UrgentPointer REG_DWORD 0 | 1 Default: 0

Dieser Eintrag legt fest, welcher Modus von TCP verwendet wird, um Urgent Data zu verarbeiten. Die beiden verschiedenen Mechanismen deuten den sog. Urgent Pointer im TCP-Header unterschiedlich. Beide Varianten sind inkompatibel. Wert

Bedeutung

0

TCP verwendet den BSD-Mechanismus.

1

TCP verwendet den in RFC 1122 beschriebenen Mechanismus.

Tab. A.149: TcpUseRFC1122UrgentPointer-Werte

Ist der Eintrag in der Registry nicht vorhanden, wird verfahren, als sei der Wert auf »0« gesetzt. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

778

TCP/IP Persistent Routes

TcpWindowSize REG_DWORD 0x0-0xFFFF Bytes Default: (siehe unten.)

Dieser Wert legt die maximale Puffergröße fest, die TCP einer Gegenstelle als sog. TCP Window Size bzw. TCP Receive Window als freien Empfangspuffer anzeigt. Der Gegenstelle wird mit Bekanntgabe der TCP Window Size gestattet, die entsprechende Menge an Bytes zu senden ohne einzelne Empfangsquittungen (TCP-ACKs) durch den Empfänger abzuwarten. Dies ist insbesondere auf langsamen WAN-Verbindungen hilfreich. Je größer der freigegebene Empfangspuffer ist, umso größer ist die Sendeleistung der Gegenstelle (oder kann es wenigstens sein). Das TCP Receive Window sollte ein Vielfaches der TCP Maximum Segment Size (MSS) sein. Die MSS bezeichnet die maximale Paketgröße, auf die sich die jeweiligen TCP-Teilnehmer für eine Session geeinigt haben. Der Vorgabewert beträgt 0xFFFF (65535), es sei denn, eine der folgenden Varianten wäre kleiner: •

das Vierfache der maximalen TCP-Datengröße auf dem Netzwerk.

•

0x2000 (8192), aufgerundet auf ein gerades Vielfaches der TCP-Datengröße auf dem Netzwerk.

Es gilt nur der jeweils größere Wert. Für Ethernet beträgt der Wert 0x2238 (8760). Die Angaben von Microsoft lassen leider nur schwer erahnen, was mit »maximum TCP data size on the network« gemeint ist. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

A.26 TCP/IP Persistent Routes HKEY_LM\System\CurrentControlSet\Services\Tcpip\Parameters\PersistentRoutes Bindable type use Tab. A.150: Registry-Schlüssel für TCP/IP Persistent Routes

TCP/IP Persistent Routes

Anhang A • Die Registry von Windows NT

779

Der Unterschlüssel »PersistentRoutes« enthält Einstellungen für fest eingestellte IP-Routen (»Persitent Routes«). Die Einträge werden durch ROUTE.EXE ab WinNT 3.51 (oder später) verwaltet. Die Einträge erfolgen im CSV-Format (Comma Separated Values) mit folgenden Aufbau: Destination,SubnetMask,Gateway,PrimaryRouteMetric

Alle Einträge in diesem Unterschlüssel enthalten Daten des Typs REG_SZ; es gibt keinen Wert im eigentlichen Wertefeld. Beispiel: 45.100.23.10,255.255.255.255,131.110.0.1,5 REG_SZ

Diese Kette steht für eine IP-Route zur IP-Adresse 45.100.23.10, bei einer Subnet-Mask von 255.255.255.255, übermittelt durch Router (Gateway) 131.110.0.1, bei einem primären Route-Metric von 5. Das Feld »PrimaryRouteMetric« wird erst ab WinNT 3.51 SP 2 (oder später) unterstützt.

A.27 TCP/IP WinSock HKEY_LM\System\CurrentControlSet\Services\Tcpip\Parameters\Winsock HelperDllName Mapping MaxSockAddrLen MinSockAddrLen Tab. A.151: Registry-Schlüssel für TCP/IP WinSock

TCP/IP – WinSock Der Unterschlüssel »Tcpip\Parameters\Winsock« enthält Werte der Windows Sockets für TCP/IP.

HelperDllName REG_EXPAND_SZ Path and file name Default: %SystemRoot%\System32\wshtcpip.dll

780

TCP/IP WinSock

Der Wert dieses Eintrages enthält den Namen der Helper-DLL-Datei der Windows Sockets, die für den TCP/IP-Transport zuständig ist. Helper-DLLs sind Laufzeit-Bibliotheken, die im User-Mode laufen; aus ihnen lernt die Windows Sockets DLL (WSock32.dll) die wesentlichen Charakteristika dieses Transports, etwa das Format der Transportadressen und der SocketOptionen. Jedes der TDI Transportprotokolle, das mit den Windows Sockets arbeitet, stellt Helper-DLLs zur Verfügung. Dieser Wert wird von der Windows Sockets DLL gesetzt; er sollte nicht geändert werden.

Mapping REG_BINARY Binary value Default: (hängt vom jeweiligen Transport ab.)

Dieser Wert gibt an: Die Adressfamilien, Socket-Typen und Protokolle, die vom jeweiligen Transportdienst unterstützt werden. Dieser Wert wird von der Windows Sockets DLL gesetzt; er sollte nicht geändert werden.

MaxSockAddrLen REG_DWORD Octets Default: 0x10

Dieser Wert gibt die Höchstlänge der Socket-Adressen an für die INET SocketFamilie. Dieser Wert wird von der Windows Sockets DLL gesetzt; er sollte nicht geändert werden.

MinSockAddrLen REG_DWORD Octets Default: 0x10

Dieser Wert gibt die Mindestlänge der Socket-Adressen innerhalb der INET Sokket-Familie an.

Anhang A • Die Registry von Windows NT

781

Dieser Wert wird von der Windows Sockets DLL gesetzt; er sollte nicht geändert werden.

A.28 W3SVC – WWW Servivces HKEY_LM\System\CurrentControlSet\Services\W3SVC\Parameters AcceptByteRanges AccessDeniedMessage AllowKeepAlives AllowSpecialCharsInShell CacheExtensions CreateProcessAsUser CreateProcessWithNewConsole DefaultLoadFile DirBrowseControl EncryptionFlags FilterDLLs GlobalExpire LogErrorRequests LogSuccessfulRequests NTAuthenticationProviders PoolIDCConnections PoolIDCConnectionsTimeOut Realm ReturnURLUsingHostName ScriptTimeout SecurePort ServerSideIncludesEnabled ServerSideIncludesExtension UploadReadAhead UsePoolThreadForCGI Tab. A.152: Registry-Schlüssel für W3SVC / WWW Servivces

Der Unterschlüssel »Services\W3SVC« (für: »WWW Services«) enthält Einträge für Dienste des World Wide Web (WWW) wie HTTP (Hypertext Transfer Protocol). Diese Einträge enthalten teilweise Einstellungen im Zusammenhang mit dem Internet Information Server (IIS).

AcceptByteRanges REG_DWORD 0 | 1 Default: 1

782

W3SVC – WWW Servivces

Dieser Eintrag legt fest, ob der WWW-Dienst den »Range«-Header von »Type Bytes« verarbeitet. HTTP verarbeitet einen eingehenden Request, der ein »Range: bytes=« Header-Feld enthält, in Übereinstimmung mit den Methoden, die im Internet-Draft »Byte Range Extensions to HTTP« vom 15.12.1995 beschrieben sind. Wert

Bedeutung

0

Der WWW-Dienst ignoriert Header mit Angaben zur Byte-Range.

1

Der WWW-Dienst aktzeptiert solche Header und meldet das mit einem »Accept-Range: bytes« Header-Feld.

Tab. A.153: AcceptByteRanges-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

AccessDeniedMessage REG_SZ String Default: "Error: Access is Denied."

Der Wert dieses Eintrages ist eine Textmeldung, die an Clients geschickt wird, denen der Zugriff auf eine Datei verweigert wird, weil sie entweder die Zugriffsberechtigung nicht haben oder das Passwort nicht eingegeben wurde. Diese Nachricht wird mit der Standardantwort versendet, die den Client über den gescheiterten Zugriff benachrichtigt. Der Wert von »AccessDeniedMessage« kann so verändert werden, dass er z.B. dem Client erklärt, wie der Zugriff auf die gewünschte Datei erlangt werden kann. Wenn der Text von »AccessDeniedMessage« HTML-Code enthält, kann die Nachricht entsprechend beim Client dargestellt werden. Wenn »AccessDeniedMessage« in der Registry nicht auftaucht oder wenn es einen leeren Wert enthält, wird keine Nachricht mit der Standardantwort versendet.

AllowKeepAlives REG_DWORD 0 | 1 Default: 1

Anhang A • Die Registry von Windows NT

783

Dieser Eintrag legt fest, ob Keep-Alive-Meldungen von HTTP versendet werden. Das Versenden von Keep-Alive-Meldungen bestätigt der Gegenstelle, dass die Verbindung bzw. Session weiter aufrecht erhalten wird (werden soll); auf diese Weise wird irrtümlichen Abbrüchen vorgebeugt; somit kann auch vermieden werden, dass nach unnötigem Verlust der logischen Verbindung mehrfach dieselbe wieder aufgebaut und initialisiert und der Datenzugriff wiederholt werden muss. Damit tragen die Keep-Alive-Meldungen letztlich dazu bei, Verzögerungen zu vermeiden. Sowohl der Client wie auch der Server müssen die HTTP Keep-AliveMeldungen unterstützen, damit sie wirken. Der Internet Information Server unterstützt die Keep-Alive-Meldungen ab Version 1.0, der Internet Explorer ab Version 2.0. HTTP Keep-Alive-Meldungen dürfen nicht verwechselt werden mit den TCP Keep-Alive-Meldungen, die anderen Regeln folgen und von denen die HTTP Keep-Alive-Meldungen unabhängig sind. Die beiden Keep-Alive-Varianten sind völlig unabhängig und beeinflussen sich nicht.

AllowSpecialCharsInShell REG_DWORD 0 | 1 Default: 0

Der Inhalt dieses Eintrages legt fest, ob Sonderzeichen wie das Ampersand-Zeichen & in der Befehlszeile von Stapelverarbeitungsdateien / Batch-Files (.bat / .cmd) erlaubt sind. Sonderzeichen können den Server zur zufälligen Ausführung von Kommandos veranlassen; somit kann das Zulassen von Sonderzeichen ein unkalkulierbares Risiko darstellen. Der Wert dieses Eintrages sollte daher nur geändert werden, wenn es unbedingt notwendig ist. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

CacheExtensions REG_DWORD 0 | 1 Default: 1

Dieser Eintrag entscheidet darüber, ob Erweiterungen zum Internet Server Application Programming Interface (ISAPI) zwischen einzelnen Verwendungen im Speicher verbleiben. ISAPI-Erweiterungen sind Dynamic Link Libraries (DLLs),

784

W3SVC – WWW Servivces

die verwendet werden, um Webseiten zusammenzusetzen, die Variablen in der Seitenanforderung enthalten. Wert

Bedeutung

0

ISAPI-Erweiterungen werden nach Verwendung auf die Festplatte zurückgeschrieben.

1

ISAPI-Erweiterungen verbleiben im Speicher, bis der Internet Information Server gestoppt wird.

Tab. A.154: CacheExtensions-Werte

Der Wert dieses Eintrages sollte nicht verändert werden. Unter normalen Umständen müssen die ISAPI-Erweiterungen im Speicher gehalten werden, damit sie ständig zur Verfügung stehen. Dieser Eintrag dient allein Testzwecken und der Fehlerdiagnose.

CreateProcessAsUser REG_DWORD 0 | 1 Default: 1

Dieser Eintrag legt fest, ob der WWW-Dienst CGI-Anwendungen ausführt (CGI = Common Gateway Interface), wenn der Client eine Seite aufruft, die über CGI zusammengesetzt wird. CGI-Anwendungen werden verwendet, um Webseiten dynamisch zu erzeugen in Abhängigkeit von Variablen, die der Anwender bei seiner Seitenanforderung übergibt. Wert

Bedeutung

0

Der WWW-Dienst unterstützt CGI-Anwendungen in Abhängigkeit von den Systemberechtigungen. Dies geschieht durch die Anwendung der Win32 CreateProcess API.

1

Der WWW-Dienst unterstützt CGI-Anwendungen in Abhängigkeit von den Benutzerberechtigungen. Dies geschieht durch die Anwendung der Win32 CreateProcessAsUser API.

Tab. A.155: CreateProcessAsUser-Werte

CGI-Anwendungen mit Systemberechtigungen zuzulassen, kann bedeuten, dass Anwender Zugriff auf Dateien erhalten, die sie sonst nicht sehen dürften. Dies würde einen gravierenden Sicherheitsmangel darstellen.

Anhang A • Die Registry von Windows NT

785

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

CreateProcessWithNewConsole REG_DWORD 0 | 1 Default: 0

Dieser Eintrag bestimmt, ob CGI-Anwendungen (CGI = Common Gateway Interface) in einem getrennten Prozess oder mit einer neuen Console laufen. CGI-Anwendungen werden verwendet, um Webseiten dynamisch zu erzeugen in Abhängigkeit von Variablen, die der Anwender bei seiner Seitenanforderung übergibt. Wert

Bedeutung

0

CGI-Anwendungen laufen als getrennter Prozess.

1

CGI-Anwendungen laufen als Prozess mit einer neuen Console.

Tab. A.156: CreateProcessWithNewConsole-Werte

CGI-Prozesse in einer neuen Console zu betreiben ist deutlich langsamer, als sie in einem getrennten Prozess laufen zu lassen. Andererseits kann der Betrieb von CGI-Prozessen in einer neuen Console erwogen werden, wenn die CGI-Anwendung I/O-Umleitungen beinhaltet. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

DefaultLoadFile REG_SZ [Path] File Name Default: Default.htm

Dieser Eintrag gibt die Standardseite an, die der Client erhält, wenn er keine Datei angibt. Üblicherweise ist diese Seite die Homepage der Website.

786

W3SVC – WWW Servivces

DirBrowseControl REG_DWORD Bit Mask Value Default: 0x4000001E (siehe unten)

Dieser Eintrag legt fest, ob die Datei, die in »DefaultLoadFile« angegeben ist, überhaupt verwendet wird und ob das Auslesen von Verzeichnissen erlaubt ist; ist dieses gestattet, legt »DirBrowseControl« die Eigenschaften der Rückgaben fest. Dieser Wert liegt in Form einer Bit-Maske vor. Die folgenden Tabellen führen die Bit-Werte auf. Wert

Bedeutung / Verhalten

0x40000000

Die in »DefaultLoadFile« angegebene Datei wird verwendet.

0x80000000

Das Auslesen von Verzeichnissen ist erlaubt.

0xC0000000

Beides zusammen: Die »DefaultLoadFile« wird verwendet und das Verzeichnisauslesen ist erlaubt.

Tab. A.157: DirBrowseControl-Werte (1)

Weiterhin: Wert

Bedeutung / Art der Anzeige bei der Verzeichnis-Ausgabe

0x00000002

Show Date – Anzeige des Datei-Datums

0x00000004

Show Time – Anzeige der Datei-Zeit

0x00000008

Show Size – Anzeige der Datei-Größe

0x00000010

Show Extension – Anzeige der Datei-Namenserweiterung

0x00000020

Display Long Date – Anzeige des Datei-Datums in Langfassung

Tab. A.158: DirBrowseControl-Werte (1)

Die ersten vier Stellen bestimmen, ob die Verzeichnisausgabe und die Anzeige der Standard-Datei EIN/AUS geschaltet sind. Die letzten vier Stellen bestimmen, mit welchen Angaben die Verzeichnisausgabe stattfindet. Um die verschiedenen Angaben bzw. Eigenschaften zu kombinieren, muss jeweils die Summe ihrer Werte gebildet werden. Um beispielsweise nur die Ausgabe von Datum und Zeit zuzulassen, muss der Wert 0x000A betragen.

Anhang A • Die Registry von Windows NT

787

Der Vorgabewert beträgt 0x40000001E: Die Standarddatei wird angezeigt, aber die Verzeichnisausgabe ist nicht gestattet. Sollte jedoch die Verzeichnisausgabe eingeschaltet werden, erfolgt sie mit der Rückgabe von Datum, Zeit, Größe und Nameserweiterung der Datei (Summe der Werte 0x2 + 0x4 + 0x8 + 0x10 = 0x1E). Um die Standarddatei, die in »DefaultLoadFile« angegeben ist, auf EIN oder AUS zu stellen, sollte die entsprechende Einstellung im Internet Service Manager vorgenommen werden. Um die Eigenschaften der Verzeichnisausgabe festzulegen, muss dieser Registry-Eintrag manuell editiert werden.

EncryptionFlags REG_DWORD 0 | 1 | 2 | 3 Default: 3

Dieser Wert legt fest, ob Verschlüsselungsprotokolle (Encryption Protocols) vom WWW-Dienst verwendet werden (sofern vom Internet Information Service unterstützt). Wert

Bedeutung

0

Es werden keine Verschlüsselungsprotokolle unterstützt.

1

Verschlüsselung durch Secure Sockets Layer (SSL).

2

Verschlüsselung durch Private Communications Technology (PCT).

3

Beides: Verschlüsselung mit SSL und PCT.

Tab. A.159: EncryptionFlags-Werte

PCT-Verschlüsselung wird bei Internet Information Server (ISS) Version 1.0 nicht unterstützt. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

FilterDLLs REG_SZ DLLName[, DLLName…] Default: Sspifilt.dll

Dieser Eintrag legt eine oder mehrere Filter-DLL für ISAPI fest, die geladen werden, wenn der WWW-Dienst gestartet wird.

788

W3SVC – WWW Servivces

DLL = Dynamic Link Library ISAPI = Internet Server Application Programming Interface

GlobalExpire REG_DWORD 0x0 | 0x1 – 0xFFFFFFFE seconds | 0xFFFFFFFF Default: 0xFFFFFFFF

Dieser Eintrag legt fest, ob der WWW-Dienst sog. »Expires Header« mit statischen Webseiten verschickt bzw. welcher Wert in diesen »Expires Header« gelegt wird. Wert (Sekunden)

Bedeutung

0x0

Die Webseite verfällt mit ihrer Übertragung und weder Client noch Proxy-Server sollen sie speichern.

0x1 – 0xFFFFFFFE

Der WWW-Dienst addiert diesen Wert zur aktuellen Zeit (Greenwich Mean Time) hinzu; das Ergebnis wird mit jedem »Expires Header« versendet, wenn eine statische Webseite auf Anforderung übertragen wird.

0xFFFFFFFF

Der WWW-Dienst sendet keine »Expires Header«.

Tab. A.160: GlobalExpire-Werte

Der »Expires Header« gibt an, wie lange die Webseite (bzw. ihr Inhalt) gültig ist. Wenn diese Zeit abgelaufen ist, darf die Seite nicht mehr vom Server zu Clients gesendet werden. »Expires Header« werden somit verwendet, um zeitabhängige Dokumente vor einer Verwendung zu schützen, wenn sie nicht mehr aktuell sind. Der Zeitwert im sog. »Expires Header« stellt also ein Verfallsdatum dar. Enthält das Dokument keine solche Zeitangabe, kann die Seite bei einem Client oder Proxy-Server zeitlich unbegrenzt aus dem jeweiligen lokalen Cache gelesen (reproduziert) werden – was im Einzelfall bedeutet, dass es auf dem Web-Server längst eine neuere Version des Dokumentes geben könnte. Wird die Verfallszeit sehr kurz angegeben, erzeugt dies bei jedem neuen Aufruf der Seite durch den Client einen neuen Internetzugriff (sofern die Zeit dann schon verstrichen ist). Hier muss zwischen Aktualität der Seiten einerseits und der Vermeidung von Internetzugriffen andererseits abgewogen werden.

LogErrorRequests REG_DWORD 0 | 1 Default: 1

Anhang A • Die Registry von Windows NT

789

Dieser Eintrag legt fest, ob der WWW-Dienst erfolglose Zugriffe in seinen Protokolldateien festhält (Transaction Logs). Jeder IIS-Dienst führt solche Transaction Logs über Zugriffe und Anforderungen. Als erfolglose Anforderungen werden solche Zugriffe angesehen, bei denen die Webseite nicht gefunden (und darum auch nicht an den Client gesendet) wurde; ihnen entsprechen Status-Codes wie etwa 401 oder 500. Wert

Bedeutung

0

NEIN – Der IIS-Dienst führt keine Transaction Logs über erfolglose Zugriffe.

1

JA – Der IIS-Dienst hält erfolglose Zugriffe in Transaction Logs fest.

Tab. A.161: LogErrorRequests-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. Siehe auch: LogSuccessfulRequests

LogSuccessfulRequests REG_DWORD 0 | 1 Default: 1

Dieser Eintrag legt fest, ob der WWW-Dienst erfolgreiche Zugriffe in seinen Protokolldateien festhält (Transaction Logs). Jeder IIS-Dienst führt solche Transaction Logs über Zugriffe und Anforderungen. Als erfolgreiche Anforderungen werden solche Zugriffe angesehen, bei denen die Webseite gefunden und an den Client gesendet wurde; ihnen entsprechen Status-Codes wie etwa 200 oder 301. Wert

Bedeutung

0

NEIN – Der IIS-Dienst führt keine Transaction Logs über erfolgreiche Zugriffe.

1

JA – Der IIS-Dienst hält erfolgreiche Zugriffe in Transaction Logs fest.

Tab. A.162: LogSuccessfulRequests-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. Siehe auch: LogErrorRequests

790

W3SVC – WWW Servivces

NTAuthenticationProviders REG_SZ Authentication scheme[, Authentication scheme…] Default: NTLM

Dieser Eintrag legt das Authentisierungsschema fest, das Clients angeboten wird, denen der Zugriff auf eine Ressource verweigert wurde. Jedes Element in der Liste erscheint mit eigenem Authentication Header in der Rückgabe an den Client, mit der dieser darüber in Kenntnis gesetzt wird, dass ihm der Zugriff verweigert wurde. Der Vorgabewert ist NTLM – dieses bezieht sich auf die WinNT Challenge/ Response-Authentisierung, die eingeschaltet sein muss. Der Eintrag von »NTAuthenticationProviders« kann verwendet werden um die Authentisierungsschemata von Dritt-Anbietern zu verwenden.

PoolIDCConnections REG_DWORD 0 | 1 Default: 0

Dieser Eintrag bestimmt, ob die Verbindung dem SQL-Server (hinterlegt im Internet Database Connector bzw. den .idc Dateien) dem IIS Connection Pool per Vorgabe zugeordnet wird. Ist dies der Fall, bleiben diese Verbindungen offen, bis der IIS gestoppt wird oder die Zeit abgelaufen ist, die im Wert von »PoolIDCConnectionsTimeOut« hinterlegt ist. Ist dies nicht der Fall, muss die Verbindung zum SQL-Server jedesmal nach Bedarf (bei Zugriff auf den SQL-Server) erneut aufgebaut und abgebaut werden. Wert

Bedeutung

0

NEIN – Die Verbindung zum SQL-Server wird nicht per Vorgabe dem IIS Connection Pool zugeordnet.

1

JA – Die Verbindung zum SQL-Server wird per Vorgabe dem IIS Connection Pool zugeordnet.

Tab. A.163: PoolIDCConnections

Unabhängig von diesem Wert in »PoolIDCConnections« (siehe Tabelle) bzw. ohne Änderung dieses Wertes kann eine Verbindung zum SQL-Server sehr wohl hinzugefügt oder beendet werden, und zwar durch Verwendung von »ODBCCon-

Anhang A • Die Registry von Windows NT

791

nection«, wobei in der IDC-Datei (.idc) entweder ein Pool-Feld auftritt (Verbindung gegeben) oder nicht (Verbindung nicht gegeben). Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. Die Leistung der SQL-Zugriffe kann gesteigert werden, wenn die Verbindung zum SQL-Server dem IDC Connection Pool zugeschlagen wird. Andererseits sollte doch eher die IDC-Datei (.idc) editiert werden und nicht die Registry. Ansonsten wird auf die Handbücher von Microsoft verwiesen. Siehe auch: PoolIDCConnectionsTimeOut

PoolIDCConnectionsTimeOut REG_DWORD 0x2 – 0x80000000 Sekunden Default: 0x1E (30)

Dieser Wert gibt an, wie lange eine ungenutzte Verbindung zum SQL-Server offen gehalten wird. Bleibt die Verbindung länger als die hier angegebene Zeit ungenutzt, schließt der Internet Database Connector die Verbindung. Dieser Wert betrifft nur SQL-Server bzw. die Verbindung zu ihnen, die im IIS Connection Pool enthalten sind. Dieser Eintrag schützt vor unnützer Belegung von Lizenzplätzen durch SQL-Server, auf die nicht zugegriffen wird. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software. Siehe auch: PoolIDCConnections

Realm REG_SZ String Default: (Host-Header oder IP-Adresse)

Dieser Wert gibt an, mit welcher Überschrift die Aufforderung des IIS-Dienstes an den Client auf Authentisierung ergeht; diese Überschrift (könnte man auch als »Stichwort« bezeichnen) taucht in der Maske auf, in der zur Eingabe von Benutzername und Passwort aufgefordert wird. Diese Aufforderung ergeht, wenn der Zugriff auf eine geschützte Seite nicht ohne Authentisierung zugelassen werden konnte und diese Seite bzw. Ressource Klartext-Authentisierung über Basic verwendet.

792

W3SVC – WWW Servivces

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

ReturnURLUsingHostName REG_DWORD 0 | 1 Default: 0

Dieser Eintrag legt fest, wie der Server in der URL identifiziert wird, die an den Client mit einem Umleitungsverweis zurückgegeben wird. Wert

Bedeutung

0

Die URL enthält den Wert im Header-Feld »Host:«. Wenn das Header-Feld nicht vorhanden ist, beinhaltet die URL die IP-Adresse der Netzwerkschnittstelle, welche die Anforderung erhalten hat.

1

Die URL enthält den Host-Namen oder den Computernamen des Servers. Wurde der Host-Name im entsprechenden Eingabefeld der DNS-Systemsteuerung eingetragen, wird dieser Name zurückgegeben; ansonsten wird der Computername des Servers zurückgegeben. Ist der Server nicht an mehrere IP-Schnittstellen gleichzeitig angeschlossen (Multihoming) und sollte das Header-Feld »Host: » nicht vorhanden sein, enthält die URL den lokalen Domain-Namen des Servers.

Tab. A.164: ReturnURLUsingHostName-Werte

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

ScriptTimeout REG_DWORD Range: 0xA – 0x80000000 Sekunden Default: 0x384 (900 Sekunden = 15 Minuten)

Dieser Eintrag legt fest, innerhalb welcher Zeit eine CGI-Anwendung (CGI = Common Gateway Interface) auf die Anforderung eines Clients zu antworten hat. Erfolgt die Antwort nicht innerhalb der gesetzten Frist, beendet IIS die CGIAnwendung und schreibt eine entsprechende Meldung in die Ereignisanzeige.

Anhang A • Die Registry von Windows NT

793

SecurePort REG_DWORD 0 – 65535 Default: 443

Dieser Wert gibt den TCP-Port an, an den Requests weitergereicht werden, die über SSL-Protokoll (Secure Sockets Layer) eintreffen.

ServerSideIncludesEnabled REG_DWORD 0 | 1 Default: 1

Dieser Eintrag bestimmt, ob der IIS mit den Funktionen von Server Side Includes (SSI) arbeitet. SSI erlaubt die Übertragung nicht nur von statischen HTML-Seiten, sondern auch von Dateien, die ihrerseits wieder andere Dateien enthalten oder die Script-Befehle ausführen. Wird SSI abgeschaltet, erhöht dies die Leistungsfähigkeit von IIS; es verbessert zudem die Systemsicherheit. Wert

Bedeutung

0

AUS – IIS verwendet kein SSI.

1

EIN – IIS arbeitet mit SSI.

Tab. A.165: ServerSideIncludesEnabled-Werte

SSI erkennt Dateien, die es zu bedienen hat, mittels der Namenserweiterung. Zulässige Namenserweiterungen sind im Wert von »ServerSideIncludesExtension« hinterlegt. Siehe auch: ServerSideIncludesExtension

ServerSideIncludesExtension REG_SZ Namenserweiterungen von SSI-Dateien Default: .stm

Dieser Eintrag kann eine Liste von Namenserweiterungen enthalten, mit denen SSI-Dateien erkannt werden. In SSI-Dateien wird seitens IIS nach Include-Befehlen gesucht. Siehe auch: ServerSideIncludesEnabled

794

W3SVC – WWW Servivces

UploadReadAhead REG_DWORD 0x0-0x80000000 Bytes Default: 0xC000 (48 KB)

Der Wert dieses Eintrages entspricht der Datenmenge, die IIS von einem Client entgegennimmt, bevor die entsprechende Applikation gestartet wird. Da die vom Client kommenden Daten in aller Regel zu Beginn Initialisierungsdaten enthalten, die seitens der Applikation benötigt werden, muss der Wert von »UploadReadAhead« ausreichen, um einen fehlerfreien Aufruf der Applikation zu gestatten. Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

UsePoolThreadForCGI REG_DWORD 0 | 1 Default: 1

Dieser Eintrag legt fest, ob der WWW-Dienst IIS Pool Threads bei CGI-Anwendungen (CGI = Common Gateway Interface) nutzt. CGI-Anwendungen werden verwendet um Webseiten dynamisch zu erzeugen in Abhängigkeit von Variablen, die der Anwender bei seiner Seitenanforderung übergibt. Wert

Bedeutung

0

NEIN – IIS verwendet keine Pool Threads für CGI-Anwendungen. IIS erzeugt einen neuen Thread, der allein der CGI-Anforderung zugordnet ist.

1

JA – IIS verwendet für CGI-Anforderungen Pool Threads.

Tab. A.166: UsePoolThreadForCGI

Pool Threads sind die wirksamste Methode, CGI-Anwendungen zu betreiben. Würde für jede CGI-Anforderung ein eigener, eigens zugewiesener Prozess eröffnet, kann dies zu erheblicher Beeinträchtigung des Systems durch die Threads führen. Andererseits ist die Verarbeitung von CGI-Anwendungen mit Pool Threads langsamer. Zudem kann es sein, dass bei Auftritt sehr vieler CGI-Anforderungen diese die IIS-Threads monopolisieren. Dieser Effekt kann ausgeglichen werden durch eine Erhöhung des Wertes von »MaxPoolThreads«.

Anhang A • Die Registry von Windows NT

795

Windows NT nimmt diesen Eintrag nicht selber vor. Der Anwender kann diesen Eintrag vornehmen entweder über einen Registry-Editor oder über sonstige Software.

A.29 WinSock HKEY_LM\System\CurrentControlSet\Services\WinSock\Parameters Transports Tab. A.167: Registry-Schlüssel für WinSock

WinSock\Parameters Entries for TCP/IP

Transports REG_MULTI_SZ Subkey[ Subkey…] Default: (der Vorgabewert hängt von der Installation ab.)

Dieser Eintrag speichert die Namen von Registry-Unterschlüsseln, die Konfigurationsdaten für die Transportdienste enthalten und die Windows Sockets unterstützen. Die Windows Sockets DLL verwenden diese Daten innerhalb der Transportdienste, um Information über jeden dieser Dienste zu finden. Ist mehr als ein Transportdienst installiert, sind die verschiedenen Unterschlüssel-Nennungen durch Kommata getrennt. Beispiel: Transports REG_MULTI_SIZE Tcpip NwlnkIpx

Die Zeile besagt, dass TCP/IP und Direct Host IPX installiert und für die Unterstützung der Windows Sockets konfiguriert sind. Konfigurationsdaten für diese Transportdienste tauchen unter den folgenden Unterschlüsseln in der Registry auf: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NwlnkIpx

Anhang B Produktbeschreibungen der wichtigsten Software-Analyzer B.1 B.2 B.3 B.4 B.5

Observer (Network Instruments) EtherPeek (WildPackets) Surveyor (Shomiti) LANdecoder32 (Triticom) CNA Pro LAN-Fox (Chevin)

798 804 807 809 812

798

Observer (Network Instruments)

Die wichtigsten Software-Analyzer nach Meinung der Autoren sind: •

LANdecoder32 (Triticom / USA)

•

Surveyor (Shomiti / USA)

•

EtherPeek/TokenPeek (WildPackets / USA)

•

Observer (Network Instruments / USA)

•

CNA Pro LAN-Fox (Chevin / UK)

Manch einer wird sich vielleicht wundern, dass an dieser Stelle der Sniffer (NAI / USA) nicht aufgeführt ist. Der Sniffer Pro ist sicherlich ein sehr gutes Tool, fällt aber in die Kategorie der Hardware-Analyzer. Die Software-Version ist aufgrund von Preis und Leistungsfähigkeit einfach unakzeptabel. Bei der Auswahl eines Analyzers kommen verschiedene Kriterien in Frage: Der LANdecoder32 und der Surveyor sind beide sehr gute Analyzer mit der Fähigkeit, Protokolle über alle sieben OSI-Layer zu decodieren. Beide besitzen ein Expertensystem, das die gängigsten Fehler findet. EtherPeek fehlt hingegen ein eigenes Expertensystem. Das für EtherPeek erhältliche Netsense (Net3broup) macht jedoch hauptsächlich Expertenauswertung im Statistikbereich. Der Observer ist in der Version 7.0 mit einem von Network Instruments eigens entwickelten Expertensystem ausgestattet. Für einen einfachen Blick ins Netz, hinsichtlich der Netzlast, Protokollverteilung, etc. eignen sich beide Tools. Der Observer bereitet die gesammelten Statistiken in vielen verschiedenen Grafiken gelungen auf. Des Weiteren kann man mit dem Observer Langzeitstatistiken des eigenen Netzes über mehrere Monate hinweg sammeln und in Berichten zusammenstellen lassen. Alle Analyzer arbeiten mit RMON I/II Probes und einige sogar mit proprietären Probes zusammen, mit Ausnahme von Etherpeek. Zu allen Produkten können Plug Ins bzw. Extensions erworben werden, für SNMP u.ä. Der LANfox von Chevin ist im eigentlichen Sinne kein Analyzer, verfügt jedoch über zahlreiche Statistikfunktionen und Packet Capture. Seine Stärken liegen im Network-Monitoring. Der LANfox arbeitet entweder mit RMON I/II Probes oder mit eigenen HS-RMON Probes (HighSpeed) in den Endgeräten, um jederzeit alle Statistiken über jede Arbeitsstation zur Verfügung zu stellen.

B.1

Observer (Network Instruments) Der Observer bietet neben den üblichen Statistiken, wie z.B. Utilization, Top Talkers, Protokollverteilung, Paarbeziehungen, Packet Capture, etc,. einige Besonderheiten.

Anhang B • Produktbeschreibungen der wichtigsten Software-Analyzer

799

Abb. B.1: Discover Network Names

Der Observer kann in einem Subnetz folgende Namen auflösen und darstellen: IP-Adressen, IPX Adressen und NetBIOS-Namen. Für IP-Adressen wird entweder der Adressbereich vorgegeben und eine Adressauflösung über ARP vorgenommen – es werden an jede IP-Adresse zwei ARPPakete gesendet – oder es werden alle IP-Pakete nach ihrer IP-Adresse ausgewertet und in die Namenstabelle eingetragen. Jeder Eintrag in der Namenstabelle ist frei editierbar, abgesehen von der MAC-Adresse. Im Network Trending Modul werden über ein voreingestelltes Intervall sämtliche Statistikdaten eines Segmentes gesammelt. Im Dashboard (siehe Abbildung) werden währends des Intervalls die wichtigsten Daten (Pakete/sek, Bytes/sek, Utilization in Prozent, Anzahl der Stationen im Segment, Anzahl der Pakete, Bytes und Protokolle) angezeigt. Die im Network Trending gesammelten Daten werden im Network Trending Viewer dargestellt. Dort werden sie in einer Baumstruktur abgelegt, nach Monaten und Tagen sortiert. Die Statistiken werden entweder für jede einzelne Station für einen ganzen Tag, für ein Intervall oder einen frei bestimmbaren Zeitraum angesammelt. Alternativ kann man sich die Statistik für alle Stationen für einen bestimmten Zeitraum anzeigen lassen.

800

Observer (Network Instruments)

Abb. B.2: Network Trending

Abb. B.3: Network Trending Viewer

Anhang B • Produktbeschreibungen der wichtigsten Software-Analyzer

801

Zu jedem einzelnen Punkt können Berichte erstellt werden.

Abb. B.4: Router Observer

Jeder im Segment erreichbare Router kann auf seine Auslastung hin überwacht werden. Die Auslastung wird anhand der eingehenden und ausgehenden Pakete gemessen, wobei die Router-Geschwindigkeit (10 Mbps, 100 Mbps, etc.) hinterlegt werden muss. Um die Verfügbarkeit eines Webservers zu kontrollieren sowie die Anzahl der Verbindungen zu einem Webserver grafisch darzustellen, kann man im Menüpunkt Web Observer eine Station auswählen, die permanent überwacht werden soll. Über einen Ping-Test wird jederzeit die Verfügbarkeit getestet. Alle Stationen, die eine oder mehrere Verbindungen zu diesem Server aufgebaut haben, werden tabellarisch mit den wichtigsten Daten dargestellt. In einem geswitchten Netz sieht ein Analyzer nur bis zum nächsten Switchport. Der Observer bietet hier die Möglichkeit, einen Switch im Ganzen zu überwachen. Vorausetzung ist, dass der Switch einen Mirror-Port besitzt und über SNMP oder Telnet konfigurierbar ist. Entweder wird per Switch-Dashboard ein bestimmter Port gewählt auf dem Analyse betrieben werden soll, ohne dass ein lästiges Umstecken erforderlich ist (dann stehen sämtliche Modi zur Verfügung), oder der Switched Oberser arbeitet im Looping Modus.

802

Observer (Network Instruments)

Abb. B.5: Web Observer

Abb. B.6: Switch Dashboard

Anhang B • Produktbeschreibungen der wichtigsten Software-Analyzer

803

Abb. B.7: Bandwidth Utilization (Switched Observer). Port Ansicht eines Switches im Looping Modus.

Abb. B.8: Internet Observer: Der Internet Observer sammelt alle wichtigen Daten der bestehenden IP-Verbindungen.

804

EtherPeek (WildPackets)

Dies bedeutet, dass alle Ports der Reihe nach kurz angesprungen und für die Statistik Informationen gesammelt werden. Nach einer Laufzeit von mindestens 15 Minuten erreichen die Daten eine Genauigkeit von 99,5% und mehr.

B.2

EtherPeek (WildPackets) Etherpeek/Tokenpeek bietet neben den üblichen Statistiken und dem Packet Capture eine Decodierung von Apple Protokollen, wie man sie ansonsten nur von teureren Analyzern gewohnt ist. Zusätzlich sind einige Tools hinzugefügt worden, die das Low-Cost Produkt durchaus erwähnenswert machen (z.B. AG Net Tools).

Abb. B.9: Übersicht der eingesammelten Pakete, mit den notwendigsten Informationen der Transport- und Session- bzw. Applikationsprotokolle.

Gerade im Bereich der Apple-Talk-Familie bietet EtherPeek eine reichhaltige Auswahl. Bei Bedarf und Vorwissen ist jedes Protokoll noch weiter edierbar. Eingesammelte Pakete können wieder ins Netz geschickt werden, um einen Fehler zu reproduzieren. Zusätzlich können die gesammelten Pakete auch wieder ediert werden. Dieses Funktion findet man sonst nur bei teuren Analyzern.

Anhang B • Produktbeschreibungen der wichtigsten Software-Analyzer

805

Abb. B.10: Detail Decode: Das Detail Decode löst die Pakete nicht streng nach OSI auf, bietet dem Benutzer aber die wichtigsten Informationen der einzelnen Protokolle.

Abb. B.11: Statistik: Die Statistiken von Etherpeek geben einen schnellen Überblick über die wichtigsten Daten im Netz.

806

EtherPeek (WildPackets)

Abb. B.12: Filter: Filter werden im Etherpeek relativ einfach über die Protokollfamilie ausgewählt.

Abb. B.13: Filter Settings – Edit Protocol

Anhang B • Produktbeschreibungen der wichtigsten Software-Analyzer

807

Abb. B.14: Edit Send

B.3

Surveyor (Shomiti) Der Surveyor nimmt eine Ausnahmestellung bei den Software-Analyzern ein. Der Surveyor ist modular aufgebaut. Das Grundmodul bietet Statistik und Packet Capture. Die Module Expert System, Traffic Generator, Remote Plug-In, QoS (Voice over IP) müssen zusätzlich erworben werden. Der Surveyor arbeitet mit jeder handelsüblichen Adapterkarte zusammen, wird mit der Shomiti eigenen Hardware jedoch ein vollwertiger Hardware-Analyzer. Der Surveyor bietet als einer der wenigen Software-Analyzer die Fähigkeit zur Decodierung der Cisco-ISL-(VLAN)Protokolle sowie der Cisco Routing Protokolle (EIGRP, HSRP). Im Resource Browser wird jede ansprechbare Ressource angezeigt, darunter fallen mehrere Adapterkarten im lokalen Rechner, extern angeschlossene Hardware (Shomiti Hardware zur Analyse) sowie per Remote verfügbare Ressourcen. Im Alarm Browser können Alarme definiert werden, die nicht nur einen einfachen Log-Eintrag erzeugen oder eine Meldung (Messages) anzeigen, sondern auch per E-Mail oder SMS verschickt werden können.

808

Surveyor (Shomiti)

Abb. B.15: Surveyor

Abb. B.16: Detail View (Expert): In der Detailansicht einer Ressource können alle Daten eines Segmentes angezeigt werden.

Anhang B • Produktbeschreibungen der wichtigsten Software-Analyzer

809

Abb. B.17: Expert Diagnosis: Zu den erkannten Fehlern wird weiterhin ein kurzer Vorschlag zur Fehlerbehebung gemacht.

Für jede Ressource wird ein Monitorfenster geöffnet, und jede Ressource kann im Detail betrachtet werden. Das Expertensystem bietet schon online eine Auswertung der wichtigsten Standardfehler.

B.4

LANdecoder32 (Triticom) Der LANdecoder32 besticht durch seine hervorragende Darstellung der Messdaten sowie einer kompletten OSI 7 Layer Darstellung. Das Expertensystem analysiert Verbindungen für IP, TCP, IPX und NCP. Die gängigsten Standardfehler werden zuverlässig erkannt und erklärt. Der LANdecoder32 arbeitet mit einem Direct Driver, der es ihm ermöglicht, unter Umgehung des NDIS Treibers direkt auf die Adapterkarte zuzugreifen. Hierdurch ergibt sich beim Paket Capture ein enormer Geschwindigkeitsvorteil. Des Weiteren werden alle MAC-Statistiken des Adapters ausgewertet und angezeigt (CRC-, Alignmentfehler etc...). In der Summary werden alle Datenpakete angezeigt. Bei der Darstellung kann zwischen MAC- und IP-Adresse gewechselt werden. Die darzustellende Schicht im Decode-Summary kann jederzeit geändert werden.

810

LANdecoder32 (Triticom)

Abb. B.18: Summary

Abb. B.19: Jedes Paket kann wiederum einzeln betrachtet werden. Auch hier wird wieder jede einzelne Schicht sauber aufgelöst und angezeigt, inklusive aller Parameter.

Das Expertensystem untersucht alle Verbindungen auf Standardfehler und zeigt geroutete Pakete. Paket #4062nm Beispiel wird an einen Router geschickt in der Annahme, dass es in ein anderes Subnetz gehört. Der Router schickt das Paket (#407) wieder in das gleiche Subnetz zurück.

Anhang B • Produktbeschreibungen der wichtigsten Software-Analyzer

811

Abb. B.20: Expert Diagnosis

Abb. B.21: Event Log

Im Event Log werden alle Statistiken, die einen frei definierbaren Schwellwert überschreiten, festgehalten. Bei Bedarf können diese Meldungen auch als E-Mail oder SMS versendet werden.

Abb. B.22: Filter

812

CNA Pro LAN-Fox (Chevin)

Abb. B.23: Frei definierbare Filter, hier durch Übernahme des im Frame markierten Parameters bzw. Werts

Wie bei keinem anderen Analyzer können im LANdecoder32 Filter gesetzt werden. Entweder wird nach einer Protokollfamilie oder nach einem bestimmten ASCI- oder HEX-Wert im gesamten Trace gefiltert. Neben dem Filtern auf MACoder IP-Adressen können über Offset-Kennungen einzelne spezifische Pakete gefiltert werden. Der LANdecoder32 verzichtet auf überflüssige Statistiken. Die wichtigsten Statistiken können in verschiedenen Auflösungen angezeigt werden. Paarbeziehungsstatistiken werden natürlich mit allen wichtigen Daten zu Verfügung gestellt.

B.5

CNA Pro LAN-Fox (Chevin) Der CNA Pro LAN-Fox ist eine effiziente Analyse- und Überwachungsplattform für alle gängigen LAN-Infrastrukturen wie Ethernet 10/100, Gigabit Ethernet, Token Ring und FDDI. Der LAN-Fox entdeckt innerhalb eines Netzes alle aktiven Komponenten und stellt diese grafisch dar.

Anhang B • Produktbeschreibungen der wichtigsten Software-Analyzer

813

Abb. B.24: Map: Die auf der Map angezeigten Stationen können editiert, z. B. die Symbole und Namen sowie deren Anordnung verändert werden.

Abb. B.25: Um ein Segment immer aktuell zu überwachen, scannt der Discovery Mode kontinuierlich nach Devices und weist gefundene Namen (IPAlias, IPX-Namen, NetBios) auf Wunsch automatisch zu.

814

CNA Pro LAN-Fox (Chevin)

Abb. B.26: Statistiken

Seine Stärke (technisch sowie im Preis-Leistungsverhältnis) liegt in der Überwachung sämtlicher Endgeräte im Netz (Clients, Server). Die hierzu benötigten HSRMON-Module kosten nur einige Mark pro Endgerät und liefern alle nötigen Aussagen. Im aktuellen Bild werden die Verbindungen einer Station angezeigt. Zu jeder Station können auf einen Blick alle Statistiken angezeigt oder das Packet Capture gestartet werden. Die Verwaltung mehrerer Segmente via Probes ist auch über Router in Netzen, die über eine WAN-Verbindung angebunden sind, möglich. Hierzu bedient sich der LAN-Fox entweder des RMON Standards oder so genannter HS-RMON Probes. Der LAN-Explorer liefert wirklich jede wichtige Statistik eines Segments. Die verschiedenen Statistiken können als Berichte weiterverarbeitet werden. Grafische Darstellungen können in vielen verschiedenen Formen angezeigt werden (Balkendiagramme, Tortengrafiken etc.).

Anhang B • Produktbeschreibungen der wichtigsten Software-Analyzer

Abb. B.27: LAN-Explorer

Abb. B.28: Zu jeder Netzwerkstation können alle relevanten Daten auf den Bildschirm gebracht werden.

815

Stichwortverzeichnis ! 55555555 249 5A5A5A5A 249 8B6T 249 /etc/.. – browmon 544 – browstat 551 – DHCP Option_1 368, 371 Option_27 371 Option_6 369 – ethers 263, 377 – exportfs 454 – exports 454, 462 – exports -access 463 – exports -anon 463 – exports -ro 462 – exports -root 463 – exports -rw 462 – exports -secure 463 – ftpusers 454, 464 – gateways 376, 379, 454, 459 – gateways und route add 460 – group 454, 456 – group und NFS 457 – hosts 454, 457 – hosts und Local Host 458 – hosts.equiv 454, 458 – hosts.equiv und rlogin 458 – nbtstat 542 – networks 454, 459 – passwd 454f. – passwd und NFS 455 – passwd und UID=0 456 – protocols 377, 401, 454, 460 – route_add 379

– services 378, 420, 454, 461 – shadow 454, 456 – TCP /etc/services 420 – traceroute 383 – Unix 453 – WinNT browmon 544 browstat 551 nbtstat 542 net_config 587 net_diag 587 net_ver 587 net_view 587 – xtab 454, 464 __MSBROWSE__, UDP Port 138 552 A A5A5A5A5 249 A/C Error 288 A/C-Bits 276, 283, 290 A/D-Wandler 166 AAAAAAAA 249 AarpRetries 654 Abfallzeit 185 Abort Delimiter 289 Abort Error 295 Absenderadresse 239 Abstract Syntax Notation 1 285 Abstraction Layer 328 AC Bit Error 294 AcceptByteRanges 781 AcceptDefaultRoutes 702 AcceptExOutstanding 691 AcceptExTimeout 691 AcceptHostRoutes 703

818

Access Control 279 – Access Priority 316 Access Priority 287, 316 AccessDeniedMessage 782 AccuCapture 247 ACK – TCP ACKs, ausstehende 433 – TCP ACKs, die keine sind 437 AckDelayTime 758 AckWindow 758 AckWindowThreshold 758 Active Analyzer 59 Active Analyzer siehe Analysatoren Active Directory 610 Active Monitor – Configuration Report Server 299 – Contention 293 – Duplicate Active Monitor 289 – Monitor Contention Process 298 – NAUN Process 290 – Report New Monitor 299 – Ring Purge 297 – Standby Monitor 298 Active Monitor Error 288f. Active Monitor Present 287 Active Montor, Duplicate Address 289 AdapterName 752 Adaptertreiber 30 Unix, route 470 AddNameQueryRetries 712 AddNameQueryTimeout 712 Address of Last Neighbor Notification 288 Address Resolution Protocol siehe ARP AddressAnswerLimit 672 Adresse – 55555555 249 – 5A5A5A5A 249 – A5A5A5A5 249 – AAAAAAAA 249 – Address of Last Neighbor Notification 288 – Address Recognized 283 – Address Verification 289 – Adressauflösung bei TCP/IP 361

Stichwortverzeichnis

– ARP 348 – Broadcast-Adresse 365 – Destination Address 239 – DNS 348 – Duplicate Address 289 – Duplicate Address Test 287, 290 – Einser-Broadcast-Adresse 370 – Functional Address 288 – Group Address 288 – IP Address 363 – IP Subnet Mask ist falsch 405 – IP-Adresse im falschen Subnet 405 – IP-Broadcast-Adresse ist falsch 405 – LANA-Nummer 538 – Locally Administered Address 306 – logische Adressen 306 – MAC Address 363 – MAC Destination Address 281 – MAC Source Address 281 – MAC-Adresse, doppelte 363 – Multicast Addresses 268 – NAUN Address 287, 291 – NAUN Change 299 – Request Ring Station Address 287 – Source Address 239 – Universally Administered Address 306 Adressen – Adressformate 154 – Destination Address 49 – duplicate IP address 47 – Filter auf IP-Adressen 402 – IP-Adressen 32 – IP-Adressen, doppelte 404 – Liste aller Server 136 – Liste der Arbeitsgruppen 136 – MAC 167 – MAC-Adressen 32 – Netzwerk 168 – Source Address 49 – TCP/UDP-Ports 32 AG Group 62 – EtherPeek 62 – TokenPeek 62 Alignment Error 58, 185, 251f.

Stichwortverzeichnis

Allowed Access Priority 287 AllowKeepAlives 782 AllowSpecialCharsInShell 783 All-Routes Broadcast 313 American National Standards Institute 164 AMP siehe Active Monitor Present Analysatoren 26 – Active Analyzer 59 – AnySpeed 466, 474 – Aufnahmekapazität 34 – Auto-Learning 48 – Bedienbarkeit 27 – Century Tap 66 – CINeMa 63 – CNA Pro 62 – Domino 66 – DOS-Analyzer 58, 252 – Dual-Port Analyzer 58 – Echtzeit-Analyzer 57 – Einsparungen 105 – EtherBoy 64 – EtherPeek 62 – External Analyzer 58 – Font 49 – Frame-Liste 49 – Geräteklassen 52 – Hand-held Analyzer 57 – Hardware-Analyzer 55 – Internal Analyzer 58 – Internet Advisor 55, 63 – InterWatch 63 – K1100 52 – Kabeltester 176, 189 – Kosten 104 – LAN Fox 62 – LAN Meter 67 – LANalyzer 52 – LANalyzer for Windows 65 – LANdecoder32 52, 66, 79, 201, 284, 406 – LANdecoder/e 238 – LANdecoder/tr 274, 304 – LANreport 79, 406 – LANwatch32 65 – Local Analyzer 53

819

– Messgeräte 26 – MicroScanner 67 – NetControl 65 – NetSense 79 – NetXRay 62 – Nicht-Echtzeit-Analyzer 57 – Observer 59, 64, 406 – Offline-Analyzer 58 – OmniScanner 67 – OneTouch 67 – Online-Analyzer 58 – PacketBoy 64 – Passive Analyzer 59 – PC-Analyzer 57 – PentaScanner 67 – ProConvert 64 – Protocol Decoding 48 – Qualitätssicherung 104 – Remote Analyzer 53 – Schriftgröße 49 – Single-Port Analyzer 58 – Sniffer 52, 64, 406 – Software-Analyzer 55 – Surveyor 52, 59, 66, 201 – TokenPeek 62 – TokenVision 194, 274, 302, 304 – Traffic Generator 59, 108 – What's Up Gold 59, 63, 477 – Win Pharaoh 63 – Windows-Analyzer 275 Analysatoren siehe DOS-Analyzer Analysatoren siehe Hardware-Analyzer Analysatoren siehe LANalyzer for Windows Analysatoren siehe Sniffer Analyse 31 – Durchsatz 518 – Ethernet 237 – Expertendiagnose 45, 514 – Fragebogen 136, 140 – ICMP 375 – IP 384, 406 – IP-Pakete, verlorene 519 – LLC 335 – Ping 506

820

– Port Scan 495 – Protocol Decoding 48 – SNAP 339 – Statistik vs. Analyse 107 – TCP 410, 423, 440 – TCP/IP 505 – Token-Ring 271 – TraceRoute 508 – UDP 441 Analyzer siehe Analysatoren Angriff, via Internet 490 AnnounceDefaultRoutes 703 AnnounceHostRoutes 704 ANSI 164 ANSI siehe American National Standards Institute Ansprechpartner 136 Antwortzeiten 80, 484 – Vermittlungslatenz 116 – What's Up Gold 484 – WinNT Server 568 AnySpeed 67, 466, 474 APIProtocolSupport 664 AppleTalk-Adapter 654 Application Layer 172 – NCP 173 – SMB 173 Application siehe Layer Applikation 74 ARB siehe All-Routes Broadcast Arbitrated Loop 157 Architekturen 147 ARP 76, 263, 348, 350, 362, 369, 373 – Broadcasts 369 – Filter 520 – Hardware Destin. Address 352 – Hardware Length 351 – Hardware Source Address 352 – Hardware Type 351 – Header 351 – Operation Code 351 – Protocol Type 351 – Software Destin. Address 352

Stichwortverzeichnis

– Software Length 351 – Software Source Address 352 arp, WinNT 582 ArpAlwaysSourceRoute 762 ArpCacheLife 763 ArpTRSingleRoute 763 ArpUseEtherSNAP 764 ASIC 55, 57 ASN.1 54, 285 Assembler-Code 29 Assign Physical Drop Number 287 ATM 53, 149f., 153 Aufabreitung 100 Aufbewahrung 100 Aufnahmekapazität 34 Ausfallkosten 28 Ausscheidungssystem 82 Außendienst-Techniker 48 Auswertung, Online-Auswertung 32 Authentisierung 171 Authorized Environment 287 AutoCacheUpdate 673 Auto-Learning 27, 48 Auto-Partitioning 246 Auto-Topology 78 B Backbone 82 BacklogIncrement 730 BackupDatabasePath 664 BackupInterval 664 BackupPeriodicity 658 Bandbreite 151 BandwidthLevel 692 Baseline 98 BcastNameQueryCount 730 BcastQueryTimeout 730 BDC 612 Beacon 185, 286, 297 – Type 287f. Benachrichtigungen, What's Up Gold 480 Benutzerprofile 614 Beobachtungszeitraum 95

Stichwortverzeichnis

Bericht 139 Betriebssystem 74 BGP 169 Big/Little Endian 171 BIND 611 bindable 621 bindform 621 BindSap 752 BindSecondaries 673 Bindungen, Reihenfolge 548 bit rate 185 Bit-Codierungen 176 Bitrate 151, 185 Bit-Übertragung 166 Blue Book Standard 257 B-Node 557 BOOTP 76, 362, 367, 402, 443 – Dialog 445 – Header 443f. – Reply 444 – Request 443 Bootstrap Protocol siehe BOOTP BPDU 266 Bridges – BPDU 266 – Source Route Bridge 284 – Source-Route Bridge 304 – Source-Routing 304 – Spanning Tree 321 – Switching Bridges 266 – Transparent Bridges 266 Bridging – Source-Route Bridging 321 – Transparent Bridging 321 Broadcast – Broadcast-Adresse 365 – WINS 532 BroadcastAddress 731 Broadcasts 84, 126, 178, 198 – Einser-Broadcast-Adresse 370 – IP-Broadcast-Adresse ist falsch 405 – NetBIOS 409, 531f., 535, 541 – WINS 552

821

browmon, WinNT 582, 584 Browser 657 – __MSBROWSE__ 546 – Hauptsuchdienst 546 – Mailslot 546 – Master Browser 546 – Suchdienst 544 – WinNT Registry 544 browstat, WinNT 582, 583 Buffer Overflow 31, 108 BufferMultiplier 645 Burst Error 185, 288, 294 Bytes 196 C CacheExtensions 783 CacheHitLimit 658 CacheResponseSize 658 CacheSecurityDescriptor 693 CacheTimeout 731 CALS siehe LLC Capturing 31, 33 Carrier Lost 246 Carrier Sense 113, 244 Century Tap 66 Change Station Parameters 287 ChangeLogSize 744 Chevin 62 – CNA Pro 62 – LAN Fox 62 CIFS 565, 612 Cinco 62 – NetXRay 62 CINeMa 63 Claim Token 286, 293, 298 – CL_TK Frames Received 288 – No CL_TK Frames Received 288 Class 622, 629 CleanupInterval 674 Client 242 Client-Segment 82 CLLS siehe LLC CMOL 319

822

CMOS 44 CNA Pro 62 Coding 176 – 4B/5B FDDI – 100 Mbps 180 – 8B6T 249 – 8B/10B Gigabit Ethernet – 1.000 Mbps 182 – 8B/6T Fast Ethernet – 100 Mbps 181 – binär 177 – Differential Manchester 278 – Differential Manchester Code 178 – Ethernet 179 – Manchester Code 178, 249 – NRZ 178 – NRZ – No Return to Zero 178 – NRZ-L – No Return to Zero/Level 179 – NRZ-M – No Return to Zero/Mark 179 – NRZ-S – No Return to Zero/Space 179 – RZ – Return to Zero 178 – Self Clocking 177 – ternär 177 – Token Ring 180 Collision 252 Collision Detection 156, 245 Collision Domain 244, 266 Collisions 244 COLS siehe LLC Community String 54 Configuration Report Server 273, 299 congestion 31 Connections 728 Connectivity 409 Constant Bit Rate 153 Constant Delay 153 Conversation Pairs 32, 195 Corporate Backbone 149 Correlator 287 Cost/Metric 398 CRC 185, 240 CRC Error 31, 242, 250ff. – Dummy CRC 245 – Jam Sequence 245, 250

Stichwortverzeichnis

CRC siehe Cyclic Redundancy Check CreateProcessAsUser 784 CreateProcessWithNewConsole 785 CRS siehe Configuration Report Server CS siehe Ethernet Carrier Sense CSMA/CD 244, 246 CurrentControlSet 87 Cyclic Redundancy Check 166 D DA-30 55 Dämpfung 184f., 242 DAT siehe Duplicate Address Test Data Flow Control 168, 201, 384 – LLC 330 – TCP 411 DatabaseCleanupInterval 665 DatabaseFile 686 DatabaseLoggingFlag 665 DatabaseName 665 DatabasePath 666, 764 Data-Link Layer 167 Data-Link siehe Layer Daten 173 Datendurchsatz 80 Datenfluss-Steuerung siehe Data Flow Control Datenströme 110 – gleichbleibende 110 – wechselnde 110 DCHP, Option 01 Subnet Mask 447 DDNS 611 DdpCheckSums 654 DECnet 363 Default Gateway 370 DefaultAutoDetectType 752 DefaultGateway 632 DefaultLoadFile 785 DefaultReceiveWindow 645 DefaultSendWindow 646 DefaultT1Timeout 712 DefaultT2Timeout 713 DefaultTiTimeout 713 DefaultTOS 765

Stichwortverzeichnis

DefaultTTL 765 DefaultZone 655 Destination Address 49, 239, 276 DHCP 76, 362, 364, 366, 402, 443, 560, 610 – DHCP Sever 371 – DHCP-Optionen für WINS 560 – Fehler IP-Endadresse 255 560 kein lokaler WINS-Server 564 Kein Standardwert 562 Knoten-Typ 0x00 561 Optionen 44/46 562 Standort des WINS-Servers 564 – Hex-Dump 446 – IP Subnet Mask ist falsch 405 – Option 27 369 – Options/vollständige Liste 447 – sieben Todsünden 560 Dhcp Client 661 DHCP Server 663 DHCP7, Fehler Knoten-Typ 0x08/0x00 564 DhcpDefaultGateway 633 DhcpIPAddress 633 DhcpNameServer 742, 765 DhcpNameServerBackup 742 DhcpNodeType 731 DhcpScopeId 732 DhcpServer 634 DhcpSubnetMask 634 DhcpSubnetMaskOpt 634 Diagnose, WinNT 571 Dienstleister 136 Differential Manchester 278 DirBrowseControl 786 Direct Drivers 247 DirectHostBinding 659 DisableAutoReverseZones 675 DisableDfs 710 DisableMemoryCache 693 DisjointNets 676 Distributed Observer 64

823

DIX 257, 369, 729 DLC siehe Data-Link Control (Protocol) DLC-Adapter 667 DNS 76, 348, 362, 409, 610 – BIND 611 – DDNS 611 – DNS Name 368 – DNS Server/IP Address 368 – LookUp 479, 502 – LookUp/Betreiber 502 – LookUp/Mail System 502 – Namensabfragen, umgekehrte 369 – Registry-Eintrag 671 – Server 545 – What's Up Gold 479 – WINS und DNS 560 DNS Zones 686 DnsPriority 630 DoD-Protokolle siehe TCP/IP Dokumenation, Webserver 101 Dokumentation 28, 77, 101, 136 – IntraNet 101 – Lageplan 136 Domain 766 Domain Name Service siehe DNS Domino 66 DontAddDefaultGateway 635 DOS-Analyzer 29, 58, 194, 252 Drei-Generationen-Messung 85 Drei-Punkt-Messungen 85 Drillverletzungen 252 DSAP siehe LLC Dual-Port Analyzer 58 Dual-Port Analyzer siehe Analysatoren Dummy CRC 245 Duplicate Active Monitor 289 Duplicate Address 289 Duplicate Address Test 287, 290 Duplicate IP Address 47 Durchsatz 484 – Messung 518 Durchschnittslast 96 During Configuration 288

824

Dynamic Host Configuration Protocol siehe DHCP DynamicBacklogGrowthDelta 646 E Echtzeit 153 – Telefonie 153 – Videokonferenz 153 Echtzeit-Analyzer 57 – siehe Analysatoren EFS 612 EIGRP 169 Eingrenzung 74, 195 – Ethernet Ort und Ursache 241 Protokoll 242 Topologie 242 – Maschine, Schicht, Ort 74 – physikalische Fehler 254 – Token-Ring, Ort und Ursache 300 Einsparungen 105 Einstrahlung 242 Empfängeradresse 239 Enabled Function Classes 287 EnableDeadGWDetect 766 EnableDhcp 635 EnableDns 732 EnableDynamicBacklog 647 EnableFuncaddr 753 EnableLmhosts 733 EnablePiggyBackAck 759 EnablePMTUBHDetect 767 EnablePMTUDiscovery 439, 768 EnablePoisonedReverse 704 EnableProxy 733 EnableProxyRegCheck 734 EnableRegistryBoot 677 EnableSecurityFilters 768 EnableSplitHorizon 705 EnableTriggeredUpdates 706 EnableWanRouter 753 Encrypting File System 612 EncryptionFlags 787

Stichwortverzeichnis

Endgeräte 131 Ending Delimiter 282 Endlosaufzeichnungen 43 Endlosmessung 244 Entry Values 663 Erdung 242 Error Recognized 301 EtherBoy 64 Ethernet 179, 237 – 55555555 249 – 5A5A5A5A 249 – 8B6T 249 – A5A5A5A5 249 – AAAAAAAA 249 – Alignment Error 251f. – Blue Book Standard 257 – Carrier Lost 246 – Carrier Sense 113, 244 – Collision 252 – Collision Detection 156, 245 – Collision Domain 244, 266 – CRC Error 250ff. – CSMA/CD 244, 246 – DIX 257, 369 – Ethernet II 240, 257f., 263, 369, 409 – Ethernet-Frame 239 – EtherType 240, 260 – Frame 239 – Frame Long 254 – Frame Loss 251 – Frame Short 250, 253 – Frame-Typ 257, 369 – IEEE 802.2 258 – IEEE 802.3 258f., 262 – Inter Frame Gap 113 – Jabber 254 – Jitter 183 – Kollisionen 30, 113, 242, 244 – Late Collisions 113, 246, 391 – Length 260 – Local Collisions 248 – Manchester Code 249 – Multicast Address 268

Stichwortverzeichnis

– Multiple Access 244 – Novell 802.3 261 – Phantom Collisions 248 – Präambel 239 – Raw Ethernet 257, 261, 409 – Remote Collisions 248 – Signal Quality Error (SQE) 245, 247, 394 – slot time 244 – Time Domain 244, 266 – Transceiver 246 – Truncated Binary Backoff Timer 247 – Type 260 EtherPeek 62 EtherSwitching 127 EtherType 240, 260 – 0x0800 520 – 0x0806 520 Excelan 52 ExcludedProviders 628 Experten-Diagnose 27, 43, 45, 514 – ICMP 514 – IP 406 – LANdecoder32 517 – Routing 514 – TCP 423, 440 Explorer Frame 313 Extended Length Sub-Vector 288 Extensions 760 External Analyzer 58 – siehe Analysatoren F Fall Time 185 FastSendDatagramThreshold 647 FCS 240 FDDI 152 Fehler – 55555555 249 – A5A5A5A5 249 – A/C Error 288 – AAAAAAAA 249 – Abort Delimiter 289 – Abort Error 295

825

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

AC Bit Error 294 Active Monitor Error 288f. Adapter-Karte 242 Adress- und Namensauflösung bei TCP/IP 361 Alignment Error 58, 185, 251f. Anschlusskabel 75 Antwortzeiten 80 Applikation 74 ARP 369 Beacon 185, 297 Betriebssystem 74 Bridges, Ersatzwege 268 Bridges, Umschaltzeiten 267 Buffer Overflow 31, 108 Burst Error 185, 288, 294 Carrier Lost 246 Claim Token 298 Client 242 Collision 58, 252 Congestion 31 CRC Error 31, 58, 185, 250ff. Dämpfung 242 Default Gateway 370 DNS Name 368 DNS Server/IP Address 368 Dummy CRC 245 Duplicate Active Monitor 289 Duplicate Address 289 Duplicate IP Address 47 Einstrahlung 242 Empfänger nicht erreichbar 373 Erdung 242 Error Recognized 301 Frame Copied 295 Frame Copied Error 289 Frame Long 242, 254 Frame Loss 251 Frame Short 58, 242, 250, 253 Frame-Typ 265 Frequency Error 289, 296 Hardware 242 Internal Error 288, 294

826

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

IP Fragmentation fehlerhaft 372 IP Fragmentation nicht erlaubt 372 IP Pakete, doppelte 393 IP Pakete, verlorene 519 IP Subnet Mask 366 IP Subnet Mask ist falsch 405 IP TTL zu gering 372 IP-Adresse im falschen Subnet 405 IP-Adresse, doppelte 363, 404 IP-Broadcast-Adresse ist falsch 405 Isolating Error Counts 288 Isolating Errors 287, 294 Jam Sequence 245, 250 Jitter 186 Kabel 242, 248 klassische Fehler 75 Knick 242 Koax-Kabel 75, 248 Kollisionen 93, 242 Kurzschluss 242 Längenfehler 32 Late Collision 83, 113, 246, 391 Line Error 288, 294 Local Collision 83, 248 Local Loop 373 Lost Frame 295 Lost Frame Error 289 Lost Frames 31, 47 Lotus-Notes 122 MAC Address 363 MAC Retransmissions 394 MAC-Adresse, doppelte 363 Meldungen 43 Monitor Contention Process 298 NAUN Address 291 NAUN Change 299 NetBIOS Name 368 Netzwerk 242 Non-Isolating Error Counts 289 Non-Isolating Errors 287, 295 Non-Isolating Soft Errors 294 Ort Backbone-Segment 82

Stichwortverzeichnis

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Client-Segment 82 Server-Segment 82 Phantom Collisions 248 Physical Layer 242 Prüfsumme 242 Prüfsummenfehler 31f. Quellen in der Physik 182 Quetschung 242 RARP 369 Receive Congestion 289, 295 Remote Collision 83, 248 Report New Monitor 299 Report Soft Error 287 Reproduktion 87, 137 Ring Error Monitor 296, 301 Ring Purge 297 Ring-Speed 185 Router 371 Router ist überlastet 372 Router, Pakete werden verworfen 372 Router, Server, Bridges 318 Routing 370 Routing-Fehler (1) 399 Routing-Fehler (2) 399 Routing-Fehler (3) 400 Runts 250 Sequence Number, Rücksprung 425 Server 242 Services doppelt via UDP und TCP 442 Signal Loss 288 Signal Quality Error 247 Signal Quality Error (SQE) 245 SMB 566 Loops in Dateizugriffen 566 SMB File Handle falsch/0xFFFF 568 SMB Write-Befehl mit 0 Bytes 567 SMB/NCP – doppelter Redirector 567 Soft Errors 292 Source-Route ist vorhanden 373 TCP ACKs, ausstehende 433 TCP ACKs, die keine sind 437 TCP Data Offset (Length), Fehler 429 TCP FIN/RST fehlen 434

Stichwortverzeichnis

– – – – – – –

TCP Keep-Alive 434 TCP Packets, retransmitted 424 TCP PSH Flag, Fehler (leere Pakete) 431 TCP SYN/RST Flags 433 TCP Window (Size) ist eingefroren 436 TCP Window (Size) sehr klein 436 TCP Window (Size) wird nicht genutzt 436 – TCP, Fehler in der Offset-Folge 423 – TNT expired 288 – Token Error 289, 295 – Überlänge 242 – Verteiler 242 – Windows Terminal Server (WTS) 438 – WINS 559 Fehlerdiagnose, Bedienbarkeit 27 Fehlermeldung 43 Festplatte 45 FHO Emden – Finger 491 – Port Scan 493 – TraceRoute 490 Fiber Optics 256 Fibre Channel 117, 149 – Arbitrated Loop 157 File Server 41 File Sharing 149 Filter 238, 244 – ARP und IP 520 – BPDU 268 – ICMP 375 – IP und ARP 520 – IP-Adressen 402 – MAC Frames 302 – MAC-Protokoll, Token-Ring 302 – MVID 286 – Offset-Filter 520 – Ring Error Monitor 301 – Source-Routing 304 – Spanning Tree 268 FilterDLLs 787 Filtering 27, 33, 43, 86 – Endlosaufzeichnungen 43 – Filtermaske 36

827

– Hex-Filter 35 – Off-Line-Filtering 33 – On-Line-Filtering 33 – On-Line-Filterings 56 – Zeitfenster 34 Filtermaske 36 Finger 491 finger, WinNT 582, 584 Flattersatz 49 Fluke 57, 67 – LAN Meter 67 – OneTouch 67 Follow Me 614 Font 49 ForwardBroadcasts 769 ForwardBufferMemory 769 Forwarders 678 ForwardingTimeout 679 Fragment ID 34 Frame 29 – Ethernet-Frame 239 – Header 239 – Lost Frame 295 – Trailer 239 Frame Capturing 27 Frame Check Sequence 251, 276, 281 Frame Check Sequence siehe FCS Frame Control 280 Frame-Liste 49 Frames 196, 239 – Bytes 196 – CRC Error 250 – doppelt 34 – Fehler 242 – Frame Control 280 – Frame Copied 283, 295 – Frame Copied Error 289 – Frame Forward 288 – Frame Long 242, 254 – Frame Loss 251 – Frame Short 58, 242, 250, 253 – Frame Status 282 – Frame-Liste 49 – Frame-Typen 257

828

– LLC Frames 285, 303 – Lost Frame Error 289 – MAC Frames 285, 302 – Pakete, doppelte 393 – Präambel 239 Frame-Typ 369 Frame-Typen, Fehler 265 Frequence Error 289 Frequency Error 296 Frequenz 239 – Alignment Error 251 – Frequency Error 289, 296 Front End Processor 272 FTP 173 FTP Software 55, 65 Full-Duplex Ports 129 Function Classes 287 Functional Address 288 Funkfrequenz 151 Funktionsadressen 308 G GarbageTimeout 707 Gateway, Default Gateway 370 Gateways 168 GeneralRetries 714 GeneralTimeout 714 Geräteklassen 52 GlobalExpire 788 GN Nettest 55, 63 – InterWatch 63 – Win Pharaoh 63 Group Address 288 Grundfunktionen 27 Guesswork 65 H Hacker, Tools 504 Half-Duplex Ports 127 Hand-held Analyzer 57 Hand-held Analyzer siehe Analysatoren Handshake 170 – TCP 418 – Three Way Handshake 414

Stichwortverzeichnis

Hardware 242 – ASIC 55, 57 – Century Tap 66 – Ethernet 242 – Hardware-Analyzer 55 – Jabber 254 – Kabeltester 176, 189, 201 – LAN Meter 67 – LAN-Adapter 55 – Media Splitters 126 – Media Taps 126 – MicroScanner 67 – Multi-Tasking 57 – OmniScanner 67 – OneTouch 67 – PentaScanner 67 Hardware-Analyzer 55 Hardware-Analyzer siehe Analysatoren Hauptspeicher 34 Hauptsuchdienst – __MSBROWSE__ 546 – Master Browser 546 – WinNT Registry 547 Header 173, 239f. – ARP 351 – BOOTP 443f. – ICMP 355, 421 – IP 352 – LLC 328 – NetBIOS 528 – PCI 328 – SNAP 338 – TCP 358, 410, 418 – Token-Ring 275 – UDP 360 HelperDllName 779 Hersteller – AG Group 62 – Chevin 62 – Cinco 62 – Fluke 57, 67 – FTP Software 55 – GN Nettest 55, 63 – Hewlett Packard 55, 63

Stichwortverzeichnis

– Ipswitch 59, 63, 477 – Kennung in MAC-Adresse 239 – LMC 63 – Microtest 57, 67 – NDG Software 64 – Net3Group 64 – Network Associates, Inc. 52, 64 – Network General 52 – Network Instruments 55, 64 – Novell 52, 55, 65 – Precision Guesswork 65 – PY Software 466, 474 – RADcom 55, 65 – RzK 65 – Shomiti 52, 66 – Siemens 52 – Synapse 79 – Triticom 52, 55, 66, 238, 274 – Wandel+Goltermann 55 Hewlett Packard 55, 63 Hewlett-Packard, Internet Advisor 63 Hex-Dump 430 – DHCP 446 Hex-Filter 35 Hi/Lo 171 Hidden 623 Hop Credit 380, 398 – IP TTL zu gering 372 Hostname 769 hostname 582 – WinNT 582, 585 HOSTS 545 HostsPriority 630 HTML-Dokumente 139 Hubs 109 I i siehe Analysatoren IBM, Mainframe 272 IBM Typ-1 Kabel 193 ICMP 347, 354, 362 – Address Format Reply 356 – Address Format/Subnet Mask 357

829

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Analyse 375 Checksum 355 Code 355 Code-Werte 356 Datagram Not Processed 357 Destination Unreachable 356, 376 Echo Reply 356 Echo Request 356 Echo Request/Echo Reply 382 Echo Request/Reply 348 Expertendiagnose 514 Filter 375 Fragmentation Needed 356, 372, 381, 598 Grenzen 384 Header 355, 421 Host Unreachable 347, 356, 373, 376 Information Reply 356 Information Request 356 Meldungen bei Umleitungen 374 Meldungen, wenn Router Pakete verwerfen 373 Message 355 Network Unreachable 356, 376 Operation 355 Parameter Problem 356 Ping 383 Pointer Failure 357 Port Unavailable 377, 421 Port/Service Unavailable 356 Protocol Unavailable 356, 377 Redirect 347, 356, 374, 378, 514 Redirect to Host 357 Redirect to Network 357 Redirect to Service/Host 357 Redirect to Service/Network 357 Router Advertisement Message 356 Router Solicitation Message 356 Service Unavailable 347, 421 Source Quench 348, 356, 372, 382, 384, 514 Source Route Not Available 356, 373 Time Exceeded 356, 380, 514, 598

830

– Time Exceeded (Reassembly Timer Expired) 347 – Time Exceeded/Reassembly Timer Expired 357, 372 – Time Exceeded/TTL Expired 347, 357, 372 – Timestamp Reply 356 – Timestamp Request 356 – TraceRoute 383 – Type 355 – Type-Werte 356 ICMPd, Network Unreachable 347 ICMPO, Address Format Request 356 Idle Symbol 278 IEEE 164 IEEE 802.1d 266 IEEE 802.2 258 IEEE 802.3 258, 262 IEEE siehe Institute of Electrical and Electronics Engineers IGMPLevel 770 IgnoreBroadcastFlag 666 IgnorePushBitOnReceives 648 IGRP 169 IMCP, Time Exceeded 384 InetInfo 690 InitAddresses 714 InitAddressFiles 715 InitConnections 715 InitialLargeBufferCount 648 InitialMediumBufferCount 649 InitialRefreshTimeout 735 InitialSmallBufferCount 649 Initialze Ring Station 287 InitLinks 716 InitPackets 717 InitReceiveBuffers 717 InitReceivePackets 718 InitRequests 719 InitUIFrames 719 Institute of Electrical and Electronics Engineers 164 IntelliMirror 614

Stichwortverzeichnis

Inter Frame Gap 113 Interface 623 Internal Analyzer 58 Internal Error 288, 294 Internal/built-in Analyzer siehe Analysatoren International Standardization Organization 164 Internet 612 Internet Advisor 55, 63 Internet Control Message Protocol siehe ICMP Internet Protocol siehe IP Internetworking 168 Intervalle 98 InterWatch 63 IP 76, 169, 352 – Analyse 384, 406 – BOOTP 367 – Broadcast-Adresse 365 – Checksum 401 – Default Gateway 370 – Destination Address 354, 402 – DHCP 366 – Don't Fragment 381 – Don't Fragment (DF) 396 – Empfänger nicht erreichbar 373 – Expertendiagnose 406 – Filter 520 – Filter auf IP-Adressen 402 – Fragment ID 34, 346, 353, 392 – Fragment ID, doppelte 393 – Fragment ID, Microsoft Lo/Hi 394 – Fragment Offset 353, 397 – Fragmentation 345, 390 – Fragmentation Flags 346, 353, 390, 395 – Header 352 – Header Checksum 354 – Header Length 346, 353, 386 – Identification 353, 392 – IP Address 363 – IP Fragmentation fehlerhaft 372 – IP Fragmentation nicht erlaubt 372

Stichwortverzeichnis

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

–

IP Subnet Mask 366 IP Subnet Mask ist falsch 405 IP TTL zu gering 372 IP und NetBIOS 408 IP, Inc. 344 IP-Adresse im falschen Subnet 405 IP-Adressen 344 IP-Adressen, doppelte 404 IP-Adressen, Filter 402 IP-Broadcast-Adresse ist falsch 405 Last Fragment 397 Last/More Fragments 353 Local Host 458 Local Loop 373, 393 Local Routing 393 MAC Padding 389 Multicasts 224.0.x.x 400 Option Record Route 383 Options 354 Padding 354 Pakete, defekte 391 Pakete, doppelte 393 Pakete, verlorene 519 Protocol 354, 401 Qualitätssicherung 407 route add 460 Routing-Fehler (1) 399 Routing-Fehler (2) 399 Routing-Fehler (3) 400 Source Address 354, 402 Source-Route ist vorhanden 373 Subnet Broadcast 365 Subnet Mask 374 Subnet, IP-Adresse im falschen 405 Time To Live (TTL) 345, 354, 380, 398 Time To Live (TTL) / WinNT Registry 600 ToS Normal/High Reliability 388 Normal/High Throughput 388 Normal/Low Delay 388 Routine Precedence 388 ToS Normal/High Reliability 353

831

– – – – – – –

ToS Normal/High Throughput 353 ToS Normal/Low Delay 353 ToS Precedence 353 Total Length 353, 388 Troubleshooting Guidelines 505 Type of Service (ToS) 353, 387 Type of Service (ToS) / WinNT Registry 601 – Version 353, 386 – WINS 366 IP address, duplicate 47 IP RIP 701 IPAddress 636 IP-Adressen 32 ipconfig, WinNT 582, 585 IPEnableRouter 770 IPInterfaceContext 636 IPO, May/Don't Fragment (MF/DF) 353 Ipswitch 59, 63, 477 – What's Up Gold 63 IPv6 150 IPX 76, 169, 408 – Checksum 261 – Novell 802.3 261 – NWLink 540 – Raw Ethernet 261 IrpStackSize 650 IsDomainMaster 659 ISO 164 ISO siehe International Standardization Organization Isolating Error, Burst Error 294 Isolating Error Counts 288 Isolating Errors 287, 294 – Abort Error 295 – AC Bit Error 294 – Internal Error 294 – Line Error 294 IsSlave 679 J Jabber 254 Jam Sequence 245, 250 Jitter 152, 183

832

K K1100 52, 55 Kabel 201, 242 – Dämpfung 242 – Einstrahlung 242 – Fehler 248 – Fiber Optics 256 – IBM Typ-1 193 – Kabeltest 289 – Kabeltester 201 – Knick 242 – Koax 192, 197, 248, 256 – Koax-Kabel 238 – Kurzschluss 242 – Quetschung 242 – Twisted-Pair 190, 197, 256 – Überlänge 242 Kabeltester 176 KeepAliveInterval 771 KeepAliveTime 771 Kerberos 612 KeyType 662 Knick 242 Knoten-Typ – WINIPCFG.EXE 558 – WINS 533, 557 Koax-Kabel 184, 192 – Schwingungsverhalten 112 Kollision, Frame Short 253 Kollisionen 30, 58, 93, 113, 242, 244 – 55555555 249 – 5A5A5A5A 249 – A5A5A5A5 249 – AAAAAAAA 249 – CRC Error 250f. – Frame Short 250 – Jam Sequence 245, 250 – Late Collisions 246, 391 – Local Collisions 248 – Phantom Collisions 248 – Remote Collisions 248 – Runts 250

Stichwortverzeichnis

Kollsionen, Truncated Binary Backoff Timer 247 Kommunikationspaare 32 Kontaktaufnahme 83 Kosten 104 Kritik 148 Kurzschluss 242 L L3-Switching 158 LAA 363 LAA siehe Locally Administered Address Ladezeiten 42 Längenbeschränkungen 155 Längenfehler 32 LAN – Architekturen 147 – ATM 53 – Backbone 82 – Bandbreite 151 – Client-Segment 82 – Ethernet vs. Token Ring 155 – Funktionsprinzip 151 – Kritik 148 – Längenbeschränkungen 155 – Load Balancing 111, 149 – Qualitätssicherung 104 – Rundfunk 151 – Server-Segment 82 – Shared Media 53, 148 – Skalierbarkeit 152 – Trends 148 – Verfügbarkeit 105 – VG-AnyLAN 53 – VLAN 149 LAN Fox 62 LAN Meter 67 LANA, NetBIOS-Nummer 538 LAN-Adapter 30, 55 LANalyzer 52 LANalyzer for Windows 30, 55, 65 – Excelan 52 LAN-Analysator 31

Stichwortverzeichnis

LAN-Architekturen 147 LANdecoder32 28, 45, 52, 55f., 66, 79, 201, 284, 406, 514, 519 – Expertendiagnose 517 LANdecoder/e 238 LANdecoder/tr 274, 304 Langzeitmessung 34, 244 LanMan Server 709 LAN-Monitor 31 LANreport 79, 406 LANwatch 55 LANwatch32 65 LargeBufferSize 650 Lastverlauf 93 Late Collision 83, 113, 246, 391 Layer – Abstraction Layer 328 – Application 75, 172 – Data-Link 75, 167 – Layer 2a MAC 167 – Layer 2b LLC 167, 328 – Network 75, 80, 168, 200 – Physical 75, 84, 166, 175, 242 – Presentation 75, 171 – Session 75, 171 – Transport 75, 80, 169, 201 Layer-3-Switching siehe L3-Switching LDAP 611 Lease 637 LeaseObtainedTime 637 LeaseTerminatesTime 637 Leistungs-Schwachstellen 116 Leitungsdurchsatz 116 Length 260 Line Error 288, 294 Links 728 ListenAddresses 680 ListenBackLog 694 Little/Big Endian 171

833

LLC 76, 167, 325, 409, 728 – Analyse 335 – Connectionless Acknowledged Link Services 327 – Connectionless Link Services (CLLS) 327 – Connection-Oriented Link Services (COLS) 327 – Control 330 – Data Flow Control 330, 334 – DISC 331 – DM 331 – DSAP 329 – FRMR 331 – Header 328 – I-Format/LLC-2 332 – Information Transfer 332 – LLC Frames 285, 303 – LLC und DLC 326 – LLC und NetBEUI 326 – LLC und NetBIOS 326 – LLC-1 (CLLS) 327 – LLC-2 (COLS) 327 – M-Bits 331 – N(r)-Bits 333 – N(s)-Bits 333 – P/F-Bit 331, 333 – REJ 334 – RNR 334 – RR 334 – SABME 332 – S-Bits 334 – Service Access Point 260 – S-Format/LLC-2 333 – SNAP 263, 320, 337 – SNAP-Header 338 – SSAP 329 – Supervisory Information 333 – TEST 332 – UA 332 – U-Format/LLC-1 330 – Unnumbered Information 330 – XID 332

834

LLCMaxWindowSize 720 LLCRetries 720 LLInterface 638 LMC 63 – CINeMa 63 LMHOSTS 545 LmhostsTimeout 735 Lo/Hi 171 Load Balancing 111, 149 Lobe Media Check 289 Lobe Media Test 287 Local Analyzer 53 Local Analyzer siehe Analysatoren Local Collision 83, 248 Local Host 458 Local Ring Number 287 Locally Administered Address 306 LocalPriority 630 LogErrorRequests 788 LogFileBatchSize 695 LogFileFlushInterval 695 LoggingLevel 707 Logical Link Control 167 Logical Link Control Protocol Data Unit 330 Logical Link Control siehe LLC Login 171 LogSuccessfulRequests 789 Lost Frame 295 Lost Frame Error 289 lost frames 31 Lotus-Notes 122 LPDU siehe Logical Link Control Protocol Data Unit lpq, WinNT 582, 586 lpr, WinNT 582, 586 LSB/MSB 171 LSB-Mode 306 M MA siehe Ethernet Multiple Access MAC 151, 167 – Adressen 167 – CRC 240

Stichwortverzeichnis

– Destination Address 239, 268, 276, 281 – Duplicate Address Test 290 – Ethernet 237 – EtherType 240 – FCS 240 – Functional Address 307 – Locally Administered Address 306 – MAC Address 363 – MAC Frames 285, 302 – MAC Padding 389 – MAC Protocol 286 – MAC-Adresse, doppelte 363 – MAC-Protokoll 278, 302 – Multicast Address 268 – Protokoll 167 – Retransmissions 394 – Source Address 239, 276, 281 – Token-Ring 271, 278 – Universally Administered Address 306 MAC Layer, Session Management 330 MAC-Adressen 32 Mailslot, Browse 546 MailslotDuplicateTimeout 746 Mailslots 540 Mainframe 272 MaintainServerList 660 Major Vector ID 285 Manchester Code 249 Map 477 Mapping 780 Master Browser 550 – __MSBROWSE__ 528 – Hauptsuchdienst 546 – Suchdienstwahl 551 – WinNT Registry 547 MasterPeriodicity 660 MasterServers 687 MaxAddresses 721 MaxAddressFiles 721 MaxConnBackLog 735 MaxConnections 722 MaxDgramBuffering 736 MaxForwardPending 638 Maximum Segment Size (MSS) siehe TCP

Stichwortverzeichnis

Maximum Transmission Unit (MTU) 439 MaximumDynamicBacklog 650 MaximumIncomingFrames 722 MaximumMailslotMessages 745 MaximumMailslotTimeout 745 MaxLinks 723 MaxMemoryUsage 724, 761 MaxNonpagedMemoryUsage 709 MaxNumForwardPackets 772 MaxPktSize 754 MaxPoolThreads 696 MaxRequests 724 MaxSockAddrLen 780 MaxTriggeredUpdateFrequency 707 MaxUserPort 772 Media Access Control siehe MAC Media Splitters 126 Media Taps 126 MediumBufferSize 651 MemoryCacheSize 697 Messbericht 139 – HTML-Dokumente 139 Messdaten 45 – Aufarbeitung 100 – Aufbewahrung 100 – On-Line-Publishing 101 – Publikation 101 Messdauer 34 – Aufnahmekapazität 34 Messtechnik siehe Analysatoren Messung – Analysefragebogen 136 – Aussagekraft 118 – bei den Endgeräten 131 – bei Einzelbetrieb 110 – bei Mischbetrieb 109 – bei Tagesbetrieb 109 – Beobachtungszeitraum 95 – Drei-Generationen-Messung 85 – Drei-Punkt-Messung 85 – Durchsatz 518 – Eingrenzung 195 – Endlosaufzeichnungen 43

835

– Endlosmessung 244 – Fragebogen 140 – Full-Duplex Ports 129 – Half-Duplex Ports 127 – Intervalle 98 – Langzeitmessung 244 – Langzeitmessungen 34 – Last-Test 121 – Mirror Port 125 – Notfall 135 – Shared Media LAN 126 – Snapshots 98 – Statistik 92, 121 – Stresstests 110 – Traffic Generator 108 – VLAN-Protokolle 128 – Welche? 108 Methodik 73 – Adressen & Namen 78 – Ausscheidungssystem 82 – Broadcasts & Multicasts 78 – Deutung 91 – Drei-Generationen-Messung 85 – Drei-Punkt-Messungen 85 – Eingrenzung 195 – Eingrenzung der Netzwerkschicht 80 – Eingrenzung des Ortes 79 – Eingrenzung physikalische Fehler 254 – Eingrenzung von Ort und Ursache 241 – Erste Schritte 76 – Grundlagen 73 – Offline-Statistik 99 – Online-Publishing 101 – Online-Statistik 99 – Qualitätssicherung 104 – Reproduktion des Fehlers 87 – Runder Tisch 138 – Snapshots 98 – Statistiken 92 – TCP/IP 361 – Techniker, externer 77 – Techniker, interner 77 – Token-Ring 300

836

– Überblick, schneller 78 – Verbindungsaufbau 83 – Verkehrstabellen 81 – Vorgehensweise 76 – Windows Registry 87 Metric/Cost 398 MicroScanner 67 Microsoft 165 Microtest 57, 67 – MicroScanner 67 – OmniScanner 67 – PentaScanner 67 MinFileKbSec 697 MinimumDynamicBacklog 651 MinSockAddrLen 780 Mirror Port 53, 83, 125, 137, 200 Misstrauen 91 Mixed Mode 615 M-Node 557 Mobile Computing 614 Modem Sharing 168 Monitor Check 289 Monitor Contention Process 298 Monitoring 31 MSB/LSB 171 MSBROWSE – Namenstypen/Tabelle 528 – UDP Port 138 552 MSS siehe Maximum Segment Size MTU 638 Multicast Address 268 Multicasts 126 Multiple Access 244 Multiple UNC Provider 710 Multiplexer 272 Multi-Tasking 57 MUP 710 MUX siehe Multiplexer MVID 285 MVID siehe Major Vector ID N NAI siehe Network Associates, Inc. Name 631

Stichwortverzeichnis

Name Space Provider 627 Named Pipes 540 Namensauflösung – DNS Name 368 – Namensabfragen, umgekehrte 369 – NetBIOS Namenstabellen 545 Namensdienste, NetBIOS 531 NameQueryRetries 725 NameQueryTimeout 725 NameServer 743, 773 NameServerBackup 743 NameServerPort 736 NameSrvQueryCount 736 NameSrvQueryTimeout 737 NAUN Address 287, 291 NAUN Change 299 NAUN Process 290, 302 NBF 539, 711 NBF Transport 728 NbProvider 737 NBT 542 nbtstat, WinNT 582, 591 NCP 76, 173 NDG Software 64 – EtherBoy 64 – PacketBoy 64 NDIS 32, 247 NDIS siehe Sniffer Nervenstärke 102 net, WinNT 582, 587 Net3Group 64, 406 – NetSense 64, 406 – ProConvert 64 NetBEUI 326, 481, 532, 534, 539, 549 – Protokollstapel 539 NetBEUI Transport Frames 711 NetBIOS 171, 326, 526, 611 – __MSBROWSE__ 528, 546 – Analyse 529 – Broadcast 409, 532, 535, 541 – Header 528 – Konfiguration unter WinNT 536 – LAN Broadcast 545 – LANA-Nummer 538

Stichwortverzeichnis

– – – – – – – – – –

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

LMHOSTS 545 Mailslots 540 Master Browser 528 MSBROWSE 528 Multicasts 535 Nachrichtentypen 534 Name Cache 545 Name Server (WINS) 545 Named Pipes 540 Namen 526 16 vs. 32 Zeichen 529 Computer, Domain 527 Namensdienste 531 Namenstabellen 545 Namenstyp 0x00 527 Namenstyp 0x01 527 Namenstyp 0x03 527 Namenstyp 0x06 527 Namenstyp 0x1B 528 Namenstyp 0x1C 528 Namenstyp 0x1D 528 Namenstyp 0x1E 528 Namenstyp 0x1F 528 Namenstyp 0x20 528 Namenstyp 0x21 528 Namenstyp 0xBE 528 Namenstyp 0xBF 528 Namenstypen/Tabelle 527 NBF 539 NetBEUI 534, 539 NetBIOS Name 368 NetBIOS over TCP 542 NetBT 534, 542 NWLink 534, 540 Protokollbindungen 536 Protokollvarianten 534 Registration am WINS Server 554 Reihenfolge der Protokollbindungen 548 Scope ID 526, 533 Scope ID/WinNT Registry 533 Subnet Broadcast 545 Suchdienst 533 Suchdienst je Transport 548

837

– UDP-TCP Ports 544 – Verbindungsaufbau 415 – WinNT Registry 538 – WinNT Registry (Überblick/1) 538f. – WinNT Registry/NWLink 540 NetBIOS over TCP/IP 729 NetBIOS over TCP/IP siehe NetBT NetBT 327, 481, 534, 538, 542, 549, 729 – NetBIOS-Dialog über TCP 543 – Protokoll-Stapel 543 – WinNT Registry 542 NetBT-Adapterparameter 742 NetbtPriority 631 NetControl 65 NetLogon 744 NetRules 620 NetSense 64, 79, 406 netstat, WinNT 582, 592 netstat -r, netstat -r 595 NetWare – IPX 523 – NCP 523 – SPX 523 NetWare Link IPX 751 Network Associates, Inc. 52, 64, 406 – Sniffer 64 Network BIAS 183 Network General 52 Network Instruments 64, 406 – Observer 64 Network Interface Card 166 Network Layer 168, 200 – Gateways 168 – Netzwerkadressen 168 – Router Exchange Protocols 169 – ungesichert 169 – verbindungslos 169 Network siehe Layer NetworkNumber 754 NetworkRangeLowerEnd 655 NetworkRangeUpperEnd 656 NetXRay 62 Netz-Eingangsstrom 183

838

Netzlast 95, 112, 119 – Durchschnittslast 96 – Lasttest 108 – pro Minute 96 – pro Sekunde 95 – Traffic Generator 108 Netzwerk – Adressen 168 – Hardware 242 Netzwerk-Management 160, 194, 472 Netzwerkschicht siehe Layer NFS 173, 455, 457, 611 NIC siehe Network Interface Card Nicht-Echtzeit-Analyzer siehe Analysatoren NLSP 169 NMPI 541 NodeType 737 Non-Isolating Error Counts 288f. Non-Isolating Errors 287, 294f. – Frame Copied 295 – Frequency Error 296 – Lost Frame 295 – Receive Congestion 295 – Token Error 295 NoRecursion 681 Normierungen 164 Notfall 135 – Analyse-Fragebogen 136 – Ansprechpartner 136 – Messung 135 Novell 52, 65 – LANalyzer for Windows 65 Novell 802.3 261 Novell NetBIOS 757 NRZ 178 nslookup, WinNT 582, 595 NTAuthenticationProviders 790 NumForwardPackets 773 NWLink 481, 534, 540, 549 – NMPI 541 – Protokollstapel 541 NwLnkIpx 538, 751 NwlnkNb 757

Stichwortverzeichnis

O ObjectCacheTTL 698 Observer 59, 64, 406 ODI 32, 247 ODI siehe Sniffer Offline-Analyzer 58 Offline-Filtering 33 Offline-Ordner 614 Offline-Statistik 99 Offset – Offset-Filter 520 – TCP 411 – TCP Seq/Ack Number 422 – TCP Sequence Number, Rücksprung 425 – TCP, Fehler in der Offset-Folge 423 OmniScanner 67 On-Board-Memory 29 On-Board-Prozessor 29 OneTouch 67 Online-Analyzer 58 Online-Analyzer siehe Analysatoren Online-Filtering 33 Online-Publishing 101 Online-Statistik 99 OperationsSupport 627 Opfer 79 OSI-Modell 163 – Header 173 – PCI 173 – PDU 173 – SDU 173 – Trailer 173 OSPF 169 P Paarbeziehungen 33 Packet Analyzer siehe Analysatoren Packet Delay Variation 152 PacketBoy 64 Padding, MAC Padding 389 Pakete, doppelt Local Loop 373 – IP Pakete, verlorene 519 – leere, mit TCP PSH Flag 431

Stichwortverzeichnis

Paketegröße, IP Fragmentation fehlerhaft 372 Paketgröße, IP Fragmentation nicht erlaubt 372 Paketvermittlung 153 Partitionen 613 Passive Analyzer 59 Passive Analyzer siehe Analysatoren PC-Analyzer 57 PC-Analyzer siehe Analysatoren PCI 173, 240, 277 PDC 550, 612 PDU 173, 277 Pegelabgleich 245 Pegelwechsel 177 PentaScanner 67 Phantom Collisions 248 Phasenverschiebungen 183 Physical Drop Number 288 Physical Layer 75, 166, 175, 242 – A/D-Wandler 166 – Alignment Error 251 – Auffinden von Fehlern 188 – Coding 176 – Fehlerquellen in der Physik 182 – Jitter 183 – Phasenverschiebungen 183 – Self Clocking 177 – Serielle Bit-Übertragung 166 – Stopf-Bits 249 – Synchronisation 177 – Taktrückgewinnung 177 Physical Location 288 Physical Unit 273 Ping 482, 506 – What's Up Gold 479 ping – WinNT 582, 596 – WinNT ping -a ~ Namensauflösung 596 – WinNT ping -f ~ Fragmentierungstest 598 – WinNT ping -j ~ IP Option Loose Source Route 602 – WinNT ping -k ~ IP Option

839

Strict Source Route 602 – WinNT ping -l ~ Einstellung der Paketlänge 597 – WinNT ping mit Zielliste 603f. – WinNT ping -n ~ Begrenzte Anzahl 597 – WinNT ping -r ~ IP Option Record Route 602 – WinNT ping -s ~ IP Option Time Stamp 601 – WinNT ping -t ~ Enloslauf 596 – WinNT ping -t ~ Hop Credit TTL 599 – WinNT ping -v ~ IP Type of Service (ToS) 600 – WinNT ping -w ~ Wartezeit bis zum Pong 603 Ping-Pong 413 PktType 754 Plan, Lageplan 136 PMAP siehe Port Mapper Protocol P-Node 557 Policy Based Networks 159 PoolIDCConnections 790 PoolIDCConnectionsTimeOut 791 PoolThreadLimit 699 Port Mapper Protocol 420 Port Scan 484 – Analyse 495 – FHO Emden 493 – What's Up Gold 484 PortName 656 Ports 168 PPTPFiltering 640 PPTPTcpMaxDataRetransmissions 774 Präambel 239 Precision Guesswork 65 – LANwatch32 65 Presentation Layer 171 – Lo/Hi 171 PriorityBoost 652 Problem – Einzel-Problem 84 – Gruppen-Problem 84

840

ProConvert 64 Product Instance ID 288 Promiscuous Mode 27, 30 Protocol Control Information siehe PCI Protocol Data Unit siehe PDU Protocol Decoding 27, 32, 48, 198 Protokoll, MAC 167 Protokolle 165 – Bindungen 548 Protokollstapel – NetBEUI/NBF 539 – NetBT 543 – NWLink 541 ProviderOrder 628 ProviderPath 631 Prozessor, Prozessorzeit 31 Prüfsumme 242 Prüfsummen 166 Prüfsummenfehler 31 – Online-Statistik 32 Psychologie 102 PU siehe Physical Unit Publikation 101 Pulse 747 PulseConcurrency 747 PulseMaximum 748 PulseTimeout1 748 PulseTimeout2 749 PY Software 466, 474 Q QoS 149 QoS siehe Quality of Service Qualitätssicherung 104, 407 – IP 407 – TCP 440 Quality of Service 149, 152, 162 QueryDriverFrequency 661 QueryWithoutSourceRouting 725 Quetschung 242 Quittungen, TCP ACKs, die keine sind 437

Stichwortverzeichnis

R RADcom 55, 65 Rahmen 239 RandomAdapter 738 Randomize 749 RARP 76, 362, 369, 402 Raw Ethernet 257, 261 RawIPAllowedProtocols 640 RcvWindowMax 760 Real Time Protocol 388 Realm 791 Receive Congestion 289, 295 ReceivePacketPoolSize 726 Re-Connection 246 RecursionRetry 682 RecursionTimeout 682 RefreshOpCode 739 RegCheck 89 Registry 87 – RegCheck 89 RegLocation 662 Relaisschaltungen 187 REM siehe Ring Error Monitor Remote (Network) MONitoring siehe RMON Remote Analyzer 53 Remote Analyzer siehe Analysatoren Remote Collision 83, 248 Remove Ring Station 287 Repeater 83, 109, 128 – Auto-Partitioning 246 – Re-Connection 246 – Runts 250 ReplicationGovernor 750 Replikationen 613 Report Active Monitor Error 287 Report NAUN Change 287 Report New Active Monitor 287 Report Poll Failure 287 Report Ring Station Address 287 Report Ring Station Attachments 287 Report Ring Station State 287

Stichwortverzeichnis

Report Soft Error 287 Report Transmit Forward 287 Reproduktion des Fehlers 87 Request For Comment siehe RFC Request Initialization 287, 289 Request Ring Station Address 287 Request Ring Station Attachment 287 Request Ring Station State 287 Resource Reservation Protocol 388 Response 286 Response Code 288 RestoreFlag 667 Retransmission, TCP Packets, retransmitted 424 Retransmissions 394 ReturnURLUsingHostName 792 ReTx siehe Retransmissions Review 624 Revisionsfähigkeit 104 RFC 53 RIF siehe Routing Information Field RII siehe Routing Information Indicator Ring Error Monitor 282, 296, 301 Ring Number 309 Ring Parameter Server 273, 290, 299, 308, 363 Ring Poll 302 Ring Poll Process 290 Ring Purge 286, 297 Ring Station Microcode 288 Ring Station Status Vector 288 Ringleitungsverteiler 131, 193, 289 Ringtopologie 301 RLV siehe Ringleitungsverteiler RMON 53, 59, 85, 194, 319, 348, 450 – Ferndiagnose 451 – RMON I 451 – RMON II 451 route, WinNT 582, 604 route add 460 Route Designator 313 Router 58, 83, 168, 201 – Default Gateway 370

841

– Fehler 371 – Gateway 168 – IP Fragmentation fehlerhaft 372 – IP Fragmentation nicht erlaubt 372 – IP TTL zu gering 372 – Pakete werden verworfen 372 – Router Exchange Protocols 169 – Router ist überlastet 372 – Routing Tables 371 – Source-Route ist vorhanden 373 RouteTimeout 708 Routing – Empfänger nicht erreichbar 373 – Expertendiagnose 514 – Fehler 370 – IP Fragmentation fehlerhaft 372 – IP Fragmentation nicht erlaubt 372 – Local Loop 373 – Routing-Fehler (1) 399 – Routing-Fehler (2) 399 – Routing-Fehler (3) 400 – Source-Route ist vorhanden 373 – Topology Map 482 Routing Information Field 276, 305, 310 Routing Information Indicator 305 Routing-Protokoll 154 RPC 171 RpcProtocol 683 RPS siehe Ring Parameter Server RTP siehe Real Time Protocol Runder Tisch 138 Rundfunk 151 Runts 250 RVSP siehe Resource Reservation Protocol RzK 65 – NetControl 65 S SAN siehe Storage Area Network SAP 168 SAP siehe Service Access Point Schicht siehe Layer Schriftgröße 49

842

Schwellwerte – IP 408 – Qualitätssicherung 408, 441 – TCP 441 Scope ID, NetBIOS 533 ScopeID 739 Screen-Shots 139 Scripts 751 ScriptTimeout 792 SCSI 150 SDLC 327 SDM siehe Space Division Multiplexing SDU 173, 277 SearchList 774 SecondaryServers 687 SecurePort 793 SecureSecondaries 688 SeedingNetwork 656 SendPacketPoolSize 726 Server 242 – File Server 41 Server-Segment 82 ServerSideIncludesEnabled 793 ServerSideIncludesExtension 793 Service Access Point 260 – siehe LLC – siehe SAP Service Data Unit siehe SDU Service Provider 627 Session, LLC 330 Session Layer 171 – Authentisierung 171 – Login 171 – Zeichensatztabellen 172 – Zugriffsschlüssel 171 Session siehe Layer SessionKeepAlive 739 Sessions, TCP 423 Shared Media 53, 245 Shomiti 52, 66, 406 – Century Tap 66 – Surveyor 66, 406 Sicherungssuchdienst 550 Siemens 52

Stichwortverzeichnis

Signal Loss 288 Signal Quality Error 245, 247, 394 Signalkodierung 177 Signallaufzeit 155 SilentRip 708 Simple Network Management Protocol siehe SNMP Single Port Analyzer siehe Analysatoren Single-Port Analyzer 58 SingleResponse 740 Single-Route Broadcast 313 Sliding Window Flow Control 413 – siehe TCP slot time 244 Size 741 SmallBufferSize 652 SMB 76, 173, 565, 612 – Fehler 566 Loops in Dateizugriffen 566 SMB File Handle falsch/0xFFFF 568 SMB Write-Befehl mit 0 Bytes 567 SMB/NCP – doppelter Redirector 567 – Verbindungsaufbau 415 SMP siehe Standby Monitor Present SMTP 173 SNA 168 – Physical Unit (PU) 273 SNAP 263 – Analyse 339 Snapshots 98 Sniffer 29, 52, 55, 64, 406 SNMP 53, 59, 173, 194, 348, 450, 496 – Community String 451, 496 – Get ifInOctets 501 – Get ifPhysAddress 499 – Get sysDescr 496 – Get sysInfo 496 – GET-Befehle 54 – private 451 – public 451 – SET-Befehle 54 – SNMP und CMIP 450 – SNMP-over-IPX 450 – Statistik, grafisch 501

Stichwortverzeichnis

– UDP 441 Sockets 168 Soft Error Report Timer 287 Soft Errors 292 Software Level 288 Software-Analyzer 32, 55 Software-Analyzer siehe Analysatoren Source Address 49, 239, 276 SourceRouteBcast 755 SourceRouteDef 755 SourceRouteMcast 756 Source-Routing 304, 309 – Source-Route ist vorhanden 373 SourceRouting 757 Space Division Multiplexing 157 Spanning Tree 266, 321 – Ersatz-Wege 268 – Topology Map 268 SQE siehe Signal Quality Error SRB siehe Single-Route Broadcast SSAP siehe LLC StandardAddressLength 653 Standby Monitor 298 Standby Monitor Present 287 Starting Delimiter 278 Statistik – Baseline 98 – Frames 196 – Offline-Statistik 99 – Online-Statistik 32, 99 – Snapshots 98 – Statistik vs. Analyse 107 Statistiken 92 Sternverteiler 109 Störfall 136 Störstrahlungen, Jitter 186 Stopf-Bits 249 Storage Area Network 149, 157 Store-And-Forward 109 Streams 760 Stress-Test 59 SubnetMask, Registry-Eintrag 641 SubVector ID 281, 285

843

Suchdienst – __MSBROWSE__ 546 – Browser 544 – Server 550 – Sicherungssuchdienst 550 – Suchdienstwahl 551 – Varianten 549 – Verhalten 549 – WinNT Registry 544 Suchdienste, NetBIOS 533 Surveyor 52, 59, 66, 201, 406 SVID 285 SVID siehe SubVector ID Swap 668 Switch 53 – Mirror-Port 83 Switches 83, 125, 201 – BPDU 266 – Full-Duplex Ports 129 – Half-Duplex Ports 127 – Media Splitter 126 – Media Tap 126 – Spanning Tree 266 – Store-And-Forward 109 – Switch-Durchgangstest 108 – Switching Bridges 266 – VLAN-Protokolle 128 Switching 150 – EtherSwitching 127 – TokenSwitching 127 Synapse 79, 406 – LANreport 79 – RegCheck 89 Synchronisation 177, 239 – Alignment Error 251 SYN-Flag 51 Systemsteuerung 90 T T1 642 T1TickOne 669 T1TickTwo 669 T2 642

844

T2TickOne 670 T2TickTwo 670 Täter 79 Takt 239 Taktrückgewinnung 177 – Alignment Error 251 TCP 76, 358 – ACK Flag 359, 415 – Acknowledge Number 359, 411, 422 – Acknowledgement (ACK) 342 – ACKs, ausstehende 433 – ACKs, die keine sind 437 – Analyse 410, 423, 440 – bi-direktional 411 – Checksum 359, 438 – Connections/WinNT Registry 421 – Control Flags 359 – Data Flow Control 384, 411 – Data Offset (Length) 359, 429 – Data Offset (Length), Fehler 429 – Destination Port 358, 418 – EnablePMTUDiscovery 439 – Expertendiagnose 423, 440 – FIN Flag 359, 415 – FIN/RST fehlen 434 – Flags 414, 431 – Flags – Übersicht 414 – Handshake 418 – Header 358, 410, 418 – Hex-Dump 430 – Keep-Alive 434 – Keep-Alive/WinNT Registry 422 – Maximum Segment Size (MSS) 343, 359, 418, 439 – MTU Black Hole Detection/WinNT Registry 440 – Offset-Folge, Fehler 423 – Offset-Kennungen 411 – Options 359 – Packets, retransmitted 424 – Port 418 – Port 139 544 – Port Scan 484 – Ports für NetBIOS 544

Stichwortverzeichnis

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Ports/WinNT Registry 421 PSH Flag 359, 415 PSH Flag, Fehler (leere Pakete) 431 Qualitätssicherung 440 Retransmissions/WinNT Registry 422 RST Flag 359, 415 Sendeaufforderung 413 Sendefreigabe 413 Sequence Number 358, 411, 422, 520 Sequence Number, Rücksprung 425 Services doppelt via UDP und TCP 442 Sessions 423 Sicherheitsfilter/WinNT Registry 420 Sliding Window Flow Control 343, 413, 435 Socket-Freigabe/WinNT Registry 422 Sockets, Auswahl 419 Sockets, Well Known 419 Source Port 358, 418 SYN Flag 359, 412, 415 SYN Flooding 432 SYN, SYN-ACK 416 SYN/RST Flags 433 SYN/WinNT Registry 433 SYN-ACK, ACK 417 SYN-Flag 51 TCP Window (Size) 413 TCP, Inc. 342 TCP-SYN 51 Three Way Handshake 414 Troubleshooting Guidelines 505 URG Flag 359, 414 Urgent Pointer 359, 439 Urgent Pointer/WinNT Registry 439 Verbindungsaufbau 415 Verbindungsaufbau MSS, Window Size 418 Verbindungsaufbau SYN, SYN-ACK 416 Verbindungsaufbau SYN-ACK, ACK 417 Window Size 342, 359, 414, 418, 435 /WinNT Registry 435 auf Null gefallen 435

Stichwortverzeichnis

ist eingefroren 436 sehr klein 436 wird nicht genutzt 436 – Window, Frozen 436 – WinNT Registry 422, 439 TCP Port 32 TCP/IP 341, 465 – /etc/.. 453 – Adress- und Namensauflösung 361 – Dead Gateway Detection/WinNT Registry 440 – DNS Name 368 – DNS Server/IP Address 368 – Einleitung 342 – Expertendiagnose 514 – IP Fragmentation fehlerhaft 372 – IP Fragmentation nicht erlaubt 372 – IP TTL zu gering 372 – klassische Fehler 361 – NetBIOS Name 368 – Ping 506 – Token-Ring 363 – TraceRoute 508 – Troubleshooting Guidelines 505 – Unix 453 – Vorgehensweise 361 TCP/IP Persistent Routes 778 TCP/IP Service Provider 629 TCP/IP WinSock 644, 779 TCP/IP-Adapter-Parameter 632 TCP/IP-Parameter 761 TcpAllowedPorts 642 TcpMaxConnectResponseRetransmissions 774 TcpMaxConnectRetransmissions 775 TcpMaxDataRetransmissions 776 TcpNumConnections 776 TcpTimedWaitDelay 777 TcpUseRFC1122UrgentPointer 777 TcpWindowSize 778 Techniker 77 – Techniker, externer 100, 136 – Techniker, interner 100 – Vermittler 102

845

Telefon 87 Telefonie 153 TELNET 173 ThreadTimeout 699 Three Way Handshake 414 – TCP 414 Time Domain 244, 266 TiTickTwo 670 TNT expired 288 – CL_TK Frames Received 288 – No CL_TK Frames Received 288 Token Error 289, 295 Token Ring 76, 180, 271, 363 – A/C Error 288 – A/C-Bits 276, 283, 290 – Abort Delimiter 289 – Abort Error 295 – Abort Sequence 394 – AC Bit Error 294 – Access Control 276, 279 – Access Priority 287, 316 – Active Monitor Error 288f. – Active Monitor Present 281, 287 – Address of Last Neighbor Notification 288 – Address Recognized 276, 283 – Address Verification 289 – Allowed Access Priority 287 – All-Routes Broadcast (ARB) 313 – Assign Physical Drop Number 287 – Attention Code 281 – Ausblick 322 – Authorized Environment 287 – Beacon 280, 286, 297 – Beacon Type 287 – Burst Error 288, 294 – Change Station Parameters 287 – Claim Token 281, 286, 293, 298 – Configuration Report Server 299 – Contention 293 – Correlator 287 – CRS 273 – Destination Address 276 – Differential Manchester 278

846

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Duplicate Active Monitor 289 Duplicate Address 289 Duplicate Address Test 287, 290 During Configuration 288 Early Token Release 323 Enabled Function Classes 287 Ending Delimiter 276, 282 Error Recognized 301 Explorer Frame 313 Express Frame 280 Extended Length Sub-Vector 288 Filter 286 Frame Check Sequence (FCS) 276, 281 Frame Control 276, 280 Frame Copied 276, 283, 295 Frame Copied Error 289 Frame Forward 288 Frame Status 276, 282 Frequence Error 289 Frequency Error 296 Function Classes 287 Functional Address 288 Funktionsadressen 308 Group Address 288 Header 275 Idle Symbol 278 Initialize Ring Station 287 Internal Error 288, 294 Isolating Error Counts 288 Isolating Errors 287, 294 LAA siehe Locally Administered Address Line Error 288, 294 LLC Frames 285, 303 LLC-SNAP 320 Lobe Media Check 289 Lobe Media Test 287 Local Ring Number 287 Lost Frame 295 Lost Frame Error 289 MAC Address 281 MAC Frames 285, 303 MAC Functional Address 307 MAC Protocol 286

Stichwortverzeichnis

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

MAC-Protokoll 278, 302 Major Vector ID 281, 285 Monitor Check 289 Monitor Contention Process 298 MVID-Werte 286 NAUN Address 287, 291 NAUN Change 299 NAUN Process 290, 302 Neuer Adapter im Ring 289 Non-Isolating Error Counts 288 Non-Isolating Errors 287 Non-Isolating Soft Errors 294 Normal Frame 280 Participate In Ring Poll 289 PDU 277 Physical Drop Number 288 Physical Location 288 Product Instance ID 288 Receive Congestion 289, 295 Relaisschaltungen 187 Remove Ring Station 287 Report Active Monitor Error 287 Report NAUN Change 287 Report New Active Monitor 287 Report New Monitor 299 Report Poll Failure 287 Report Ring Station Address 287 Report Ring Station Attachments 287 Report Ring Station State 287 Report Soft Error 287 Report Transmit Forward 287 Request Initialization 287, 289 Request Ring Station Address 287 Request Ring Station Attachment 287 Request Ring Station State 287 Response 286 Response Code 288 RIF/Bridge Number 313 RIF/Direction 311 RIF/Largest Frame Size 312 RIF/Length 311 RIF/Ring Number 313 RIF/Route Designator 313

Stichwortverzeichnis

– – – – – – – – – – – –

RIF/Routing Type 310 RII 305 Ring Error Monitor 296, 301 Ring Number 309 Ring Parameter Server 290, 299, 308, 363 Ring Poll 302 Ring Poll Process 290 Ring Purge 281, 286, 297 Ring Station Microcode 288 Ring Station Status Vector 288 Ring-Topologie 301 Routing Information Field (RIF) 276, 305, 310 – Routing Information Indicator 305 – RPS 273 – Set Adapter Defaults 289 – Signal Loss 288 – Single-Route Broadcast (SRB) 313 – Soft Error Report Timer 287 – Soft Errors 292 – Software Level 288 – Source Address 276 – Source-Routing 304, 309 – Standby Monitor Present 281, 287 – Starting Delimiter 276, 278 – SubVector ID 281, 285 – SVID-Werte 287 – Token Error 289, 295 – TokenSwitching 321 – TokenVision 302 – Transmit Forward 287 – UAA 306 – Vector ID 285 – Vector Length 285 – Vector Value 285 – Vorgehensweise 300 – Wrap Data 288 TokenPeek 62 TokenSwitching 127, 321 TokenVision 194, 274, 302, 304 Tools – 4Net 67 – Any Speed 67

847

– – – – – – – – – – – – – – – – – – – – – – – – – – – –

Big Brother 68 Free Wizard 68 Hacker-Tools 504 IDyle GimmIP 68 Internet Anywhere Toolkit 68 Internet Maniac 68 IP Network Browser 68 IP Sentry 69 IP Subnet Calculator 69 NeoTrace 69 NetCat 69 NetoScope 69 Netscan Tools 69 Ping Plotter 70 PortFlash 70 Recon-1 lite 70 Remote Logout 70 Remotely Possible 70 Servers Alive? 70 ShareWare-Liste 473 Sniff It 71 Subnet Wiz 71 TCP/IP 465 TCP/IP Tools für Windows 472 Tools vs. Netzwerk-Management 473 Visual Route 71 Windows-Tools für TCP/IP 466 Windows-Tools zur Netzwerkdiagnose 571 – WinNT Tools (Microsoft) 581 Toolw, Remote Logout 70 Topology, Map 477 Topology Map 268 ToS siehe Type of Service Trace 100 – Bibliothek 100 Trace And Performance Adapter, Kollisionen 31 TraceRoute 63, 481, 490 – FHO Emden 490 – What's Up Gold 478 tracert, WinNT 582, 605 Traffic Generator 59, 108

848

Trailer 173, 239 Training 29 Transceiver 246 Transmission Control Protocol siehe TCP Transmit Forward 287 TransmitIoLength 653 Transparent Bridges 266 Transport Layer 169, 201 – abgesichert 170 – Datenfluss-Steuerung 170 – Handshake 170 – Verbindungsaufbau 170 – verbindungsorientiert 170 TransportBindName 741 Transports 795 Treiber 30, 165 – AccuCapture 247 – Direct Drivers 247 Triticom 28, 45, 52, 55, 66, 79, 238, 274, 406 – LANdecoder32 66 – TokenVision 194 Truncated Binary Backoff Timer 247 TTL, IP TTL zu gering 372 TTL siehe IP Twisted-Pair 190 – Alignment Error 251 – Drillverletzungen 252 Type 689 type 625 Type of Service 149, 159 U UAA 363 UAA siehe Universally Administered Address UCP – Port 137 532 – Sicherheitsfilter/WinNT Registry 420 – Sockets, Auswahl 419 UDP 343, 360 – Analyse 441 – Checksum 360

Stichwortverzeichnis

– Destination Port 360 – Doppelte Zugriffe 442 – Header 360 – Length 360 – Port 137 544, 551 – Port 138 544, 547, 552 – Port 138 und MSBROWSE 552 – Port Scan 484 – Ports für NetBIOS 544 – Ports/WinNT Registry 421 – Services doppelt via UDP und TCP 442 – Sicherheitsfilter/WinNT Registry 443 – SNMP 441 – Source Port 360 UDP Port 32 UdpAllowedPorts 643 Überlänge 242 Übertragungszeit 153 ungesichert 169 Unit, Route 466 Universally Administered Address 306 Unix – /etc/.. 453 – arp 466 – finger 466f. – ipconfig 467 – Kommandos 466 – lpconfig 466 – lpq 466, 468 – lpstat 466, 468 – netstat 466, 468 – ping 466, 469 – snmp 466 – snmp start|stop 471 – traceroute 466, 471 Update 751 UpdateFrequency 709 Uplink 84 UploadReadAhead 794 Usability 409 use 625 UseAcceptEx 700 UseDatabase 690

Stichwortverzeichnis

UseDixOverEthernet 671, 727 UsePoolThreadForCGI 794 User Datagram Protocol siehe UDP User Restrictions 626 UserTokenTTL 701 UseZeroBroadcast 644 V Vector – Major Vector ID 281 – SubVector ID 281 – Vector ID 285 – Vector Length 285 – Vector Value 285 Verbindungsaufbau 83, 170 – TCP SYN/RST Flags 433 – TCP-NetBIOS-SMB 415 verbindungslos 169 Verfahrensregeln 165 Verfügbarkeit 105 Verkehrstabellen 81, 195 Vermittlungslatenz 116 Vertrauensstellungen 613 Verzögerungen 123 Verzögerungszeiten 153 – Vermittlungslatenz 116 VG-AnyLAN 53 Videokonferenz 153 VLAN 127, 149, 160, 388 – VLAN-Protokolle 128 Voltpegel 113 Vorbeugen 103 Vorgehensweise 76 Vorgesetzte 28, 100 W W3SVC 781 WAN 148 Wandel+Goltermann 55 – Domino 66 WanNameQueryRetries 727 WAN-Tester siehe Analysatoren Wavelength Division Multiplexing 156

849

Wavetek Wandel Goltermann siehe Wandel+Goltermann WDM 156 WDM siehe Wavelength Division Multiplexing Werkzeug 25 What's Up Gold 59, 63, 477 – Antwortzeiten 484 – Benachrichtigungen 480 – DNS Lookup 479, 483 – Durchsatz 484 – Net Tools 481 – NetBEUI 481 – NetBT 481 – NWLink 481 – Ping 479, 482 – Port Scan 484 – Routing-Karte 482 – Topology Map 482 – TraceRoute 478, 481 WildPackets 62 Win Pharaoh 63 Win95/98, WINIPCFG.EXE/Knoten-Typ 558 Windows 165, 545 – Analyzer 275 – Eingabeaufforderung 582 – Fehler 165 – HOSTS 545 – Kommandos 582 – LANA-Nummer 538 – LMHOSTS 545 – Networking 525 – Registry 87 – Systemsteuerung 90 – TCP/IP Tools für Windows 472 – Terminal Server (WTS) 438 – Tools für TCP/IP 466 – Tools zur Netzwerkdiagnose 571 Windows 2000 609 – Active Directory 610 – BDC 612 – Benutzerprofile 614

850

– CIFS 612 – DHCP 610 – DNS 610 – EFS 612 – Follow Me 614 – Integration 614 – IntelliMirror 614 – Internet 612 – Kerberos 612 – LDAP 611 – Migration 614 – Mixed Mode 615 – Mobile Computing 614 – NetBIOS 611 – NFS 611 – Offline-Ordner 614 – Partitionen 613 – PDC 612 – Replikationen 613 – SMB 612 – Vertrauensstellungen 613 Windows Internet Name Server siehe WINS Windows Internet Name Service siehe WINS Windows Registry 87 – CurrentControlSet 87 Windows-NT-Registry 350 WINIPCFG.EXE 558 WinNT – apr 582 – arp 582 – BackupPeriodicity 548 – B-Node 557 – browmon 582, 584 – browstat 582f. – DNS 545 – Eingabeaufforderung 582 – finger 582, 584 – H-Node 557 – hostname 582, 585 – HOSTS 545 – Infektionen & Wilderei 569 – ipconfig 585

Stichwortverzeichnis

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

IsDomainMasterBrowser 548 Knoten-Typ 557 Kommandos 582 Konfiguration NetBIOS 536 LANA-Nummer 538 Lmannounce 548 LMHOSTS 545 lpq 582, 586 lpr 582, 586 Mailslots 540 MaintainServerList 548 Memory-Tuning/Speed-Up 568 M-Node 557 Named Pipes 540 NBF 539 nbtstat 582, 591 net 582, 587 NetBEUI 534, 539 NetBIOS 526, 534 NetBIOS Konfiguration 536 NetBIOS Namen 526 NetBIOS over IPX 540 NetBIOS over TCP/IP 542 NetBIOS Scope ID 526 NetBIOS-Bindungen 536 NetBT 534, 538, 542 NetBT Protokollstapel 543 netstat 582, 592 netstat -e 595 netstat -s -p icmp 593 netstat -s -p ip 593 netstat -s -p tcp 594 netstat -s -p udp 594 Networking 525 Node Type 557 nslookup 595 nsloopup 582 NWLink 534, 540 NWLink Protokollstapel 541 NwLnkIpx 538 ping 582, 596 ping -a ~ Namensauflösung 596 ping -f ~ Fragmentierungstest 598

Stichwortverzeichnis

– ping -j ~ IP Option Loose Source Route 602 – ping -k ~ IP Option Strict Source Route 602 – ping -l ~ Einstellung der Paketlänge 597 – ping -l -n mit verschiedenen Längenwerten 604 – ping mit kombinierten Parametern 604 – ping mit Zielliste 603 – ping -n ~ Begrenzte Anzahl 597 – ping -r ~ IP Option Record Route 602 – ping -s ~ IP Option Time Stamp 601 – ping -t ~ Endloslauf 596 – ping -t ~ Hop Credit TTL 599 – ping -v ~ IP Type of Service (ToS) 600 – ping -w ~ Wartezeit bis zum Pong 603 – P-Node 557 – Protokollbindungen 536 – Reihenfolge der Protokollbindungen 548 – Route 582, 604 – Server mit langen Antwortzeiten 568 – Speicherverwaltung 568 – Systemsteuerung Dienste 537 – Tools (Microsoft) 581 – tracert 582, 605 – WINS-Manager WinNT Registry 350 – ARP 370 – Browser 544 – Computer-Name 368 – Dead Gateway Detection 440 – Default Gateway 371 – DHCP 365 – DNS Name 368 – DNS Server 384 – DNS Server/IP Address 369 – Hauptsuchdienst 547 – IP Default Gateway 379 – IP Fragmentation 397 – IP Sicherheitsfilter 377, 401

851

– – – – – – –

IP Statische Routen 380 IP Subnet Broadcast 406 IP Subnet Mask 367, 371, 406 IP Time To Live (TTL) 380, 398, 600 IP Type of Service (ToS) 388, 601 Master Browser 547 Maximum Transmission Unit (MTU) 382, 397, 599 – Memory-Tuning/Speed-Up 569 – MTU Black Hole Detection 440 – NetBEUI/NBF 539 – NetBIOS 538 – NetBIOS (Überblick/1) 538 – NetBIOS (Überblick/2) 539 – NetBIOS Name 368 – NetBIOS Namen 526 – NetBIOS over IPX 540 – NetBIOS over TCP/IP 542 – NetBIOS Scope ID 533 – NetBT 542 – NWLink 540 – Ports für TCP-UCP 421 – Socket-Freigabe 422 – Statische IP-Routen 376 – Suchdienst 544 – TCP Connections 421 – TCP Keep-Alive 422 – TCP Retransmissions 422 – TCP SYN 433 – TCP Urgent Pointer 439 – TCP Window Size 435 – TCP/IP Erkennung schlechter Routen 440 – TCP-UDP Sicherheitsfilter 420 – Token-Ring Source-Routing 316 – UCP-TCP Sicherheitsfilter 378 – UDP Sicherheitsfilter 443 – WinNT Registry 433 – WINS Client 559 – WINS Node Type/Knoten-Typ 557 WinNT-Registry, Node Type/KnotenTypen 558 WINS 76, 362, 366, 409, 531, 552, 611

852

– – – – – – – – – – – – – – – – – – –

B-Node 557 Broadcast 532 Broadcasts 552 Client für WinNT Registry 559 DHCP-Optionen für WINS 560 DNS und WINS 560 Fehler 559 H-Node 557 Knoten-Typ 533, 557 M-Node 557 Namensabfragen, umgekehrte 369 Node Type 557 Node Type/Knoten-Typ/WinNT Registry 557 Node Type/Knoten-Typen 557 P-Node 557 Registration 554 Registry 559 Replikationen 555 Tabellen 559

Stichwortverzeichnis

– WINS-Manager WinsDownTimeout 741 WinSock 795 WINSt, WINS Client/WinNT Registry 559 Workflow 160 Wrap Data 288f. WriteAuthorityNs 684 WriteAuthoritySoa 685 WWW 434 WWW Servivces 781 X XDR, Zeichensatztabellen 172 Z Zeichensatzzabellen 172 Zeitfenster 34, 244 ZoneList 657 Zugriffsschlüssel 171