Netzwerkanalyse, Fehlersuche, Testberichte
Home / News
Netzwerkanalyse
Grundlagen
Verkabelung
Erste Schritte
Baselining
Let's sniff
Tools
Auswerten/Filtern
Typische Probleme 1
Typische Probleme 2
Sicherheit
Bücher
Tutorials
Cacti
DSL einrichten
DynDNS einrichten
m0n0wall | pfSense
Nmap
VirtualBox
Wireshark
Forum
Shop
FAQ
Know How
Testberichte
Hardware-DB
Events
Netzwerklexikon
Links / Service
Suche
Kontakt
Impressum
Feedback
Sitemap
Partner
Unser Partner für
SSL Zertifikate
ist Checkdomain GmbH.
Netzwerkanalyse

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)


Doppelte Loopback-Adressen auf Routern

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.

eLeFaNts - Long Fat Networks

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

TCP Performance = Windows Size geteilt durch RTT

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.

Bandwidth-Delay Produkt ist gleich Bandbreite mal Verzoegerung

In einer 10 MBit/s-Leitung mit einem Delay von 10 ms befinden sich also schon 10.000 Bit.

10000 Bit = 10000000 / 0,001 sec

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:

Window Size = RTT mal Bandbreite

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.

Delayed Acknowledgements

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.

Eine Applikation funktioniert nicht...

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.

Performance im Windows-Umfeld

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.

SMB Performance ist gleich Buffersize geteilt durch RTT

 

Windows Event ID 8021

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.

Multiuserbetrieb mit Microsoft Access

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.

Performance bei Oracle

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.

Voice over IP

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.

CodecBitrate Codec
[kbit/s]
Bitrate Ethernet
[kbit/s]
G.7116488
G.7226488
G.7236,422
G.726-242447
G.726-323255
G.726-404064
G.7281632
G.729832
iLBC13,327
GSM1335
Speex2 bis 44variabel

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.

 

<-- Typische Probleme Teil 1 Inhalt Netzwerksicherheit -->

 

 
© 2004-2015, network lab - we make your net work - Netzwerkforum
aktualisiert am 22.03.2012