Typische Problemsituationen Teil 2
In diesem Kapitel werden Situationen
vorgestellt, die in der Praxis immer wieder vorkommen. Die Reihenfolge
orientiert sich am OSI-Modell.
Einige Beschreibungen wurden aus Gründen der Übersichtlichkeit in eigene Dokumente ausgelagert.
Inhalt
Doppelte Loopback-Adressen auf Routern
eLeFaNts - Long Fat Networks, Bandbreite ist nicht Alles
Delayed Acknowledgements
SMB-Signing - Systemfehler 1240 (anderes Dokument)
Eine Applikation funktioniert nicht...
Performance im Windows-Umfeld
Windows Systemfehler 1219 (anderes Dokument)
Windows Event ID 4226 (anderes Dokument)
Windows Event ID 8021
Multiuserbetrieb mit Microsoft Access
Performance bei Oracle
Voice over IP (VoIP)
Adressen auf den Loopback-Interfacen
von Routern werden oft mit einer /32-Netzmaske vergeben.
Routingprotokolle wie OSPF verwenden diese Adresse dann als Kennung
für den Routingprozess. Ist diese Kennung nicht eindeutig im
Netzwerk, werden Routen von den betroffenen Router immer wieder
verworfen.
Oft wird bei der Untersuchung von
Performanceproblemen nur die Bandbreite einer Verbindung betrachtet.
Aber bei gerade bei steigender Bandbreite wird die Laufzeit einer
Verbindung immer wichtiger.
Selbst unter idealen Bedingungen
überträgt TCP nur
Bis zu diesem rechnerischen Wert spielt
die reale Bandbreite des Links nur eine geringe Rolle. Sie darf
natürlich nicht unter diesem Wert liegen.
Wo liegen die Ursachen für dieses
Verhalten?
TCP arbeitet mit einem Sliding Window.
Der Sender erwartet spätestens nachdem er ein komplettes Window
(max. 64 Kbyte) gesendet hat ein ACK vom Empfänger. Erst danach
sendet er weitere Daten.
Die Daten bewegen sich in einer Leitung
aber nicht unendlich schnell sondern mit ca. 60 bis 80 Prozent der
Lichgeschwindigkeit im Vakuum. Es gibt also immer Daten die sich
zwischen Sender und Empfänger in der Leitung befinden. Man
spricht von „On the wire data“ oder „In flight
data“. Die Menge dieser Daten berechnet sich aus dem Produkt
von Bandbreite und Delay.
Dieses Produkt aus Bandbreite und
Verzögerung eines Links nennt man Bandwidth-Delay Produkt.
In einer 10 MBit/s-Leitung mit einem
Delay von 10 ms befinden sich also schon 10.000 Bit.
Kritisch wird es, wenn das gesamte
TCP-Window „in flight“ ist. Dann kann TCP nicht mehr
kontinuierlich senden und wartet nach jedem gesendeten Window auf ein
Acknowledge.
Die Window Size um einen Link zu
sättigen errechnet sich daher wie folgt:
Moderne TCP/IP-Implementierungen
unterstützen eine TCP-Option zur Vergrößerung der
Window Size. Dabei wird ein zusätzlicher Multiplikator
festgelegt, der es ermöglicht, die Window Size bis auf über
ein Gigabyte zu erhöhen. Der Aufbau TCP-Header bleibt also unverändert.
Unter Windows steuert der Key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts
die Verwendung von Window Scaling und Time Stamps im TCP-Header.
Bei der Suche nach Performance sollte
man die physikalischen Gegebenheiten allerdings nicht außer
acht lassen. Die Übertragung eines Ethernet-Frames (1518 Byte)
inclusive Preamble und Inter Frames Gap dauert bei Fastethernet 123
µs. Die Deltatime zwischen zwei Fullsize Frames kann im
Analyser diesen Wert eigentlich nicht unterschreiten.
Tip: Der Network General Sniffer schreibt beim Export nach CSV aus einem
gefilterten Trace zufällige Werte in die Deltatime. Als
Workaround kann man aus dem Filter über das Kontextmenü ein
neues Window erzeugen oder die fraglichen Frames als neue Datei
abspeichern. Dann funktioniert auch der CSV-Export.
Tip: Für die Analyse und Simulation solcher Probleme eignet sich ein WAN-Emulator.
Weitere Details dazu finden Sie in Apposite Linktropy Mini - WAN-Emulator im Praxistest.
Zur Entlastung des Netzwerkes muss TCP
nicht nach jedem empfangenen Segment ein ACK senden. Normalerweise
sendet TCP ein ACK wenn es zwei Segmente mit maximaler Größe
empfangen hat. Werden weniger Daten empfangen, sendet TCP spätestens
nach 200 ms ein ACK. Dieses ACK bezeichnet man dann als Delayed
Acknowledgement.
Tip: Der Experte im Network General Sniffer meldet „ACK too long“
wenn nach 100 ms kein ACK gesendet wird. Der RFC 1122 definiert
allerdings 500 ms als Timer. Typisch sind die schon genannten 200 ms.
Den Grenzwert im Sniffer kann man unter "Tools/Expert Options/Alarms/Connections" einstellen.
Problematisch sind Delayed ACK's, wenn
der Sender kleine Datenmengen sendet dann auf ein ACK wartet. Dann
entstehen in der Kommunikation immer wieder Pausen bis zu 200 ms.
Ein Kandidat für dieses Problem
ist Lotus Notes. Beim Übertragen sendet Notes jeweils 16 KB und
wartet dann auf das ACK vom Client.
Unter Windows kann es im Zusammenhang mit SMB Signing zu Performanceproblemen kommen.
und gibt keine vernünftige
Fehlermeldung aus. Die typische Situation sieht ja oft so aus: Der
Aplikationsverantwortliche zuckt mit den Schultern, Client- und
Serveradmins weisen jede Schuld von sich. Also bleibt nur noch das
Netz! Aber mit Hilfe eines Traces ist recht schnell die Ursache
ermittelt.
Nach den folgenden Symptomen sollte man
suchen:
DNS – Suche nach nicht vorhandenen Hosts
Oft gibt es Anfragen nach nicht
vorhanden Host. Ursache kann u.a. ein fehlender Domainname sein. Dann
arbeitet die Appliktion nur, wenn sich Client und Server in der
gleichen DNS-Domain befinden.
Windows 2000 und XP haben einen lokalen DNS-Cache.
Der Cache kann mit dem Kommando ipconfig /flushdns löschen.
Um den DNS-Cache abzuschalten, ist der Dienst "DNS Client" zu deaktivieren.
Zugriff auf nicht vorhandene IP-Adressen
Eigentlich sollte das feste Kodieren
von IP-Adressen in der Applikation unter Strafe stehen. Ändert
sich dann die Adresse eines Servers, geht nichts mehr. Solche
Situationen können über Filter auf ICMP und TCP SYN
lokalisiert werden.
Zugriff auf nicht vorhandene Shares und Dateien / fehlende Rechte
Probleme beim Zugriff melden SMB-Server
(Windows, SAMBA) recht zuverlässig.
Im Wireshark liefert der Filter
„smb.nt_status != 0x0“ das gewünschte Ergebniss.
HTTP
Im Web-Umfeld lohnt sich ein Filter auf
HTTP-Returncodes ungleich 200. Aufmerksamkeit sollte man auch der
Benutzung von Proxys schenken. Soll diese Verbindung wirklich über
den Proxy laufen?
Datenbank-Server
Eigentlich erfordern alle Datenbanken
eine Anmeldung. Hier sollte man sich die spezifischen Serverantworten
ansehen und entsprechend filtern.
Performanceprobleme
Die Analyse von Performanceproblemen
ist auf die Schnelle kaum machbar. Ein Blick auf das Datenvolumen
lohnt sich aber immer.
Wenn man z.B. im Eingabefenster einen
Wert eingibt und die Applikation eine einzelne Zahl zurückliefert,
dann sollten im Trace nicht tausende von Frames mit etlichen
Megabytes Daten zu sehen sein. Wenn diese großen Datenmengen
dann noch in Frames mit einer Größe unter der möglichen
MTU übertragen werden, sollte man hier weitersuchen.
Tip: In Wireshark kann man über den Ausdruck
frame.time_delta > 5 sehr gut Pausen in der Kommunikation farblich
hervorheben. Die Zeit wird in Sekunden angegeben.
Windows benutzt zur Datenübertragung
ein Protokoll namens CIFS/SMB. Grundlegendes Problem von SMB ist das
fehlende Sliding Window. Anders als TCP/IP arbeitet SMB mit einem
festen Puffer. Nach dem Senden des Pufferinhaltes wartet der Sender
auf eine Bestätigung vom Empfänger. Das führt bei
Verbindungen mit hoher Round Trip Time und einem kleinen Puffer zu
schlechter Performance.
Windows kennt drei verschiedene Modi
beim Übertragen von Daten: Core SMB, Raw SMB und den Large
ReadX/WriteX Mode. Nicht alle Windowsversionen unterstützen alle
Modi. Es kann sogar vorkommen, das beim Kopieren aus dem Explorer und
der Eingabeaufforderung unterschiedliche Modi ausgewählt werden
und so andere Übertragungsraten zustande kommen. Eine Station
meldet beim „Negotiate Protocol Response“ ihre
unterstützten Modi:
Negotiate Protocol Response im Wireshark
In Microsofts Knowledge Base finden
sich eine Reihe von Artikel zu diesem Thema.
Titel
|
Artikelnummer in der KB
|
Description of Windows 2000 TCP Features
|
224829
|
High Rate of Collisions on 100-Megabit Networks
|
169789
|
TCP/IP and NBT Configuration Parameters for Windows 2000 or
Windows NT
|
120642
|
TCP/IP and NBT Configuration Parameters for Windows XP
|
314053
|
Modify the Default SizReqBuf Value in Windows 2000
|
320829
|
Slow File Write from Windows 2000 to Windows NT 4.0 Server
|
279282
|
SMB Block Size Negotiation When Copying Files with Windows NT
Explorer
|
223140
|
Der folgende Trace zeigt eine
Übertragung mit einem SMB-Puffer von 4292 Byte auf einem Link
mit einer RTT von 55 ms und einer Bandbreite von 10 Mbit/s. Nachdem
der Sender seinen Puffer geleert hat wartet er 55 ms auf die
Bestätigung vom Empfänger bevor er erneut sendet. Das
eigentliche Senden der Daten dauert dagegen nur 50 µs.
Source Dest Size Delta Time Summary
client server 1514 0.000.214 CIFS/SMB: C Write AndX H=0804 Bytes=4292, Start=258636
client server 1514 0.000.019 NETB:Data, 1460 bytes
client server 1493 0.000.040 NETB:Data, 1439 bytes
server client 60 0.054.480 TCP:D=4346 S=139 ACK=50251263 WIN=8760
server client 105 0.001.728 CIFS/SMB: R Write AndX Status=OK
client server 1514 0.000.544 CIFS/SMB: C Write AndX H=0804 Bytes=4292, Start=262928
client server 1514 0.000.018 NETB:Data, 1460 bytes
client server 1493 0.000.014 NETB:Data, 1439 bytes
server client 60 0.054.317 TCP:D=4346 S=139 ACK=50255622 WIN=8760
server client 105 0.001.426 CIFS/SMB: R Write AndX Status=OK
client server 1514 0.000.540 CIFS/SMB: C Write AndX H=0804 Bytes=4292, Start=267220
client server 1514 0.000.019 NETB:Data, 1460 bytes
client server 1493 0.000.015 NETB:Data, 1439 bytes
server client 60 0.054.364 TCP:D=4346 S=139 ACK=50259981 WIN=8760
server client 105 0.001.535 CIFS/SMB: R Write AndX Status=OK
client server 1514 0.000.568 CIFS/SMB: C Write AndX H=0804 Bytes=4292, Start=271512
client server 1514 0.000.021 NETB:Data, 1460 bytes
client server 1493 0.000.014 NETB:Data, 1439 bytes
server client 60 0.055.401 TCP:D=4346 S=139 ACK=50264340 WIN=8760
server client 105 0.000.593 CIFS/SMB: R Write AndX Status=OK
Trace einer SMB-Übertragung
Mit dieser Technik werden also
lediglich 4 kByte in 55 ms übertragen. Umgerechnet sind das
immerhin 576 kBits/s. Die verfügbaren 10 Mbit/s werden nicht
einmal zu 10 Prozent ausgeschöpft.
Die Anwender, die natürlich nach
mehr Bandbreite verlangen, werden recht enttäuscht sein, wenn
die neue 34 Mbit/s-Leitung mit einer RTT von 50 ms in Betrieb geht.
Eine Erhöhung des SMB-Puffers und
der TCP Window Size würde hier vermutlich eher eine merkliche
Verbesserung bringen. Der entsprechende Key in der Registry lautet
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SizReqBuf
und kann maximal auf 65535 gesetzt
werden. Größere Puffer belegen allerdings auch mehr RAM
auf dem Server.
Die maximale SMB Performance wird also
durch die Größe des Puffers und die Round Trip Time
begrenzt.
Der Event 8021 kann durch eine unglückliche Konfiguration von IP
Helper-Adressen auf Cisco-Routern
ausgelöst werden.
Das Kommando "ip helper-address 10.0.0.1" auf einem Interface
eines Routers bewirkt, das
bestimmte Broadcastframes aus diesem Segment an die angegebene IP-Adresse
weitergeleitet werden.
Per default werden Broadcast mit den UDP-Zielports
- Trivial File Transfer Protocol (TFTP) (port 69)
- Domain Naming System (port 53)
- Time service (port 37)
- NetBIOS Name Server (port 137)
- NetBIOS Datagram Server (port 138)
- Boot Protocol (BOOTP) client and server datagrams (ports 67 and
68)
- TACACS service (port 49)
- IEN-116 Name Service (port 42)
weitergeleitet.
Oft möchte man allerdings nur die Funktion von DHCP sicherstellen. Das
Weiterleiten von
NetBIOS-Datagrammen an den DHCP-Server ist eher ein unerwünschter
Nebeneffekt.
Besonders negativ wirkt sich die Weiterleitung von Domain/Workgroup
Announcement (UDP Port 138) aus.
In diesen Paketen steht der aktuelle Masterbrowser für ein Subnet.
Gelangt ein solches Paket nun zu einem Computer in einem anderen Subnet,
nutzt dieser einen falschen
Masterbrowser. Dieser kann sich dann z.B. hinter einer langsamen
Wählverbindung befinden.
Ist der im Announcement genannte Masterbrowser für den Computer
garnicht ansprechbar, weil z.B.
die Namensauflösung nicht funktioniert, wird ein Event 8021 ins Log
geschrieben:
Event id: 8021
Source: Browser
Description: The browser was unable to retrieve a list of servers from the
browser master on the network \device\. The data
is the error code.
Das fragliche Paket sieht dann so aus:
User Datagram Protocol, Src Port: netbios-dgm (138), Dst Port: netbios-dgm
(138)
Source port: netbios-dgm (138)
Destination port: netbios-dgm (138)
Length: 219
NetBIOS Datagram Service
Message Type: Direct_group datagram (17)
Source Port: 138
Datagram length: 197 bytes
Source name: MEINNAME11<00> (Workstation/Redirector)
Destination name: <01><02>__MSBROWSE__<02><01> (Browser)
SMB (Server Message Block Protocol)
SMB Header
Server Component: SMB
SMB Command: Trans (0x25)
Transaction Name: \MAILSLOT\BROWSE
SMB MailSlot Protocol
Opcode: Write Mail Slot (1)
Priority: 1
Class: Unreliable & Broadcast (2)
Size: 60
Mailslot Name: \MAILSLOT\BROWSE
Microsoft Windows Browser Protocol
Command: Domain/Workgroup Announcement (0x0c)
Update Count: 0
Update Periodicity: 15 minutes
Domain/Workgroup: MYDOOM
OS Major Version: 3
OS Minor Version: 10
Master Browser Server Name: MEINNAME11
Auf den Router kann man mit dem Kommando "no ip forward-protocol
udp" die Arbeitsweise
der IP-Helper beeinflussen. Mit "no ip forward-protocol udp 138"
werden keine NetBIOS-Datagramme
mehr an den als Helper angegebenen Host gesendet.
Access zeigt im Netz folgendes
Verhalten: Beim ersten Zugriff auf eine Tabelle liest der Client die
komplette Tabelle ein. Alle weiteren Zugriffe erfolgen dann lokal und
mit guter Performance. Bei Änderungen in der Tabelle wird auf
dem Server eine Änderungsmarkierung gesetzt.
Greifen nun weitere Clients auf die
selbe Tabelle zu, wird es problematisch. Jedes mal wenn eine Client
die Änderungsmarkierung setzt, dazu reicht eine Änderung in
einer Zelle, lesen alle anderen Clients beim nächsten Zugriff
auf diese Tabelle wieder die komplette Tabelle ein.
Wenn also an einigen Clients Daten in
eine Tabelle erfasst werden hat man einen praktischen Lastgenerator
für sein Netz. Für den Anwender wirkt sich dieses Verhalten
besonders störend aus, wenn er nur eine Verbindung mit geringer
Bandbreite zum Server hat.
Oracle verwendet zur Datenübertragung
ein Protokoll namens TNS. Dieses setzt auf TCP auf, implementiert aber
leider ein Stop-and-Wait-Mechanismus. Die Performance hängt also
stark von der Packetgröße und der Round Trip Time ab.
Der Network General Sniffer hat einen guten Decode
für Oracels TNS (Transparent Network Substrate Protocol) und Net
SQL.
Eine Sprachübertragung beginnt mit
dem Verbindungsaufbau. Hierfür gibt es verschiedene Protokolle,
die in der Regel auf TCP aufsetzen:
H.323, H.225, H.224
SIP, SDP
Skinny
Der Aufbau einer Verbindung und das
Aushandeln von Parametern kann recht gut im Analyser beobachtet
werden.
Die eigentlichen Sprachdaten werden
dann mit dem Realtime Transport Protocol (RTP) über UDP
übertragen. Zur Steuerung des Realtime Datenstromes kann RTCP
(Realtime Transport Control Protocol) genutzt werden.
Für die Kodierung der Audiodaten
können verschiedene Codecs zum Einsatz kommen.
Codec | Bitrate Codec [kbit/s] | Bitrate Ethernet [kbit/s] |
G.711 | 64 | 88 |
G.722 | 64 | 88 |
G.723 | 6,4 | 22 |
G.726-24 | 24 | 47 |
G.726-32 | 32 | 55 |
G.726-40 | 40 | 64 |
G.728 | 16 | 32 |
G.729 | 8 | 32 |
iLBC | 13,3 | 27 |
GSM | 13 | 35 |
Speex | 2 bis 44 | variabel |
Tabelle Audio Codecs
Auf die Qualität einer
Sprachübertragung haben mehrere Faktoren einen Einfluß.
Sehen wir uns diese der Reihe nach an.
Packetverluste
Kommen RTP-Packete nicht an, sinkt
natürlich die Sprachqualität. Ab ca. 10 Prozent Verlustrate
wird die Störung für den Anwender hörbar.
Es gibt Codecs, wie zum Beispiel iLBC, die etwas robuster.
Packetreordering
Datenpacktete die in der falschen
Reihenfolge ankommen sind bei Sprachübertragung natürlich
recht problematisch.
Delay
Die Verzögerung ist bei einer
bidirektionalen Übertragung eine sehr wichtige Größe.
Nachdem man am Telefon einen Satz beendet hat, erwartet man ja
eigentlich eine sofortige Reaktion vom Gesprächspartner. Bis zu
150 ms Delay werden kaum als störend bemerkt. Oberhalb von 300
ms wird die Verzögerung als sehr störend wargenommen.
Die Verzögerung wird zum einem durch den verwendeten Codec bestimmt.
Gerade bei Software-Codecs auf älterer Hardware kommen da schnell einige 10 ms zusammen.
Dazu kommt dann noch das Delay im Übertragungsnetzwerk.
Zur Messung des Delays im Netzwerk kann der Administrator z.B. das Kommando
"ping" verwenden. In neueren IOS-Versionen bietet Cisco einen "Response Time Reporter" RTR an.
Der RTR kann bestimmte Links auf ihre Verzögerung hin überwachen und SNMP-Traps versenden.
Jitter
Jitter bezeichnet die Veränderung des Delays zwischen den einzelnen Packeten.
Die Auswirkung von Jitter hängen
sehr stark vom Jitterbuffer der beteiligten Stationen ab.
Zur Analyse von Problemen eignet sich
Wireshark. Da RTP nicht auf einer festen Portnummer arbeitet, wird ein
RTP-Datenstrom von Wireshark nur als UDP dekodiert. Über den
Menüpunkt Tools – Decode As kann man dem Analyser aber
mitteilen, daß es sich um RTP handelt. Unter Tools –
Statistics – RTP Analysis... kann man dann den Datenstrom
analysieren. Dort hat man sogar die Möglichkeit, das Gespräch
als Audiodatei abzuspeichern. Diese kann man sich dann anhören
und eine subjektive Beurteilung vornehmen. Selbstverständlich
nur mit Zustimmung der Gesprächspartner.
|