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
•
... 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
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 ; 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
