Ein zu hoher Paketverlust, lange Antwortzeiten oder falsche Paketreihenfolgen als Resultat des Pings weisen auf eventuelle Probleme mit der Netzwerk-Hardware hin. Treten diese Symptome bei der Kommunikation über eine oder mehrere WAN-Verbindungen auf, sind hohe Paketlaufzeiten normal. Entstehen diese Probleme im LAN, sollten Sie die Netzhardware überprüfen. Im LAN sollten nur minimale Paketlaufzeiten (im Bereich von ms) und so gut wie keine Paketverluste auftreten. Die Pakete sollten immer in der richtigen Reihenfolge eintreffen. In einem Ethernet geben diese Fehler direkte Hinweise auf eine falsche Terminierung, ein schadhaftes Kabelsegment oder fehlerhafte Hardware-Komponenten. Die Ergebnisse des Ping-Tests geben wichtige Anhaltspunkte zur weiteren Fehlersuche.

Hier sei noch einmal auf das für die Netzwerkanalyse notwendige Protokollverständnis hingewiesen. Im Prinzip werden bereits bei einem einfachen Ping-Test zwei Protokolle genutzt, die in ihrer Wirkung verstanden sein müssen. Neben dem bereits genannten ICMP-Protokoll kommt bei Ping zusätzlich noch das ARP-Protokoll zum Einsatz. Zunächst sind die Netzwerkschichten klar zu unterscheiden. Systeme im Ethernet-Netzwerk kommunizieren auf Layer 2 mittels Ethernet Frames, wobei die Adressierung über MAC-Adressen erfolgt. Die darüber liegende Netzwerkschicht IP als Layer 3-Protokoll nutzt Ethernet als Transportmedium. Beide Schichten arbeiten unabhängig voneinander. Damit ein IP-Paket, in diesem Beispiel ICMP, sein Ziel erreichen kann, muss dessen MAC-Adresse bekannt sein, da IP als Payload im Ethernet-Frame transportiert wird.

Dies kann direkt die MAC-Adresse des Zielsystems sein, wenn sich dieses im selben Ethernet-Segment befindet. Es kann auch die MAC-Adresse eines Routers sein, beispielsweise die des "Default Gateways". An dieser Stelle setzt das Address Resolution Protocol an. Vereinfacht dargestellt wird zunächst geprüft, ob die MAC-Adresse bereits bekannt ist (ARP-Cache).Wenn nicht, wird ein ARP-Request in einem Ethernet Frame mit der eigenen MAC- und IP-Adresse sowie der Ziel-IP-Adresse an die Ethernet-Broadcast-Adresse "FF-FF-FFFF-FF-FF" gesendet. Systeme im selben Segment empfangen diesen Frame und prüfen, ob die enthaltene IP-Adresse mit der eigenen übereinstimmt. Ist dies der Fall, senden sie einen ARP-Reply, ergänzt mit der eigenen MAC-Adresse, an die MAC-Adresse des Senders. Dieser trägt dann die Informationen in seinen ARP-Cache ein. Sobald die Zuordnung von IP zu MAC-Adresse verfügbar ist, kann die Kommunikation über IP, beispielsweise ICMP, erfolgen.

Der beschriebene Prozess läuft im Normalfall so schnell ab, dass die zugehörigen Pakete nur mit einem Analysewerkzeug sinnvoll dargestellt werden können. Zwischen den zusammengehörenden Paketen können beim Messen auf dem Trunk-Port durchaus einige hundert andere Pakete liegen. Daher ist es ratsam, die hintereinander folgenden Datenpakete einer Verbindung über entsprechende Display- oder auch Capture-Filter darzustellen. Ohne solche Filter kann bereits die Auswertung einer einfachen ARP-Kommunikation sehr lange dauern. In der Regel ist eine solche Analyse in der Praxis zum Scheitern verurteilt, da die für die Analyse notwendigen Pakete in der Vielzahl aufgezeichneter Informationen untergehen können. Beim Einsatz von Capture-Filtern ist allerdings zu beachten, dass alle für die geplante Analyse relevanten Datenpakete durchgelassen werden. Auch hier ist das entsprechende Hintergrundwissen unabdingbar.

Befindet sich der Server nicht im gleichen Netz wie der Client, wird auf Basis des ARP-Protokolls die MAC-Adresse des "Default Gateway" ermittelt. Der ICMP-Request wird anschließend an die MAC-Adresse des Default Gateways übermittelt. Als Ziel IP-Adresse ist im ICMP-Request die Serveradresse eingetragen. Ist die Server IP-Adresse nicht bekannt, müssen Sie diese ebenfalls mit einem zusätzlichen Protokollmechanismus ermitteln. Hierzu nutzen Sie das Domain Name System (DNS). Das DNS stellt für sich selbst ein sehr komplexes System dar. Ohne ein funktionierendes DNS sind die meisten Funktionen zwischen Client und Server zum Scheitern verurteilt. Viele Fehler in den Netzwerken liegen an einem falsch oder schlecht gepflegten DNS und diese Fehler nehmen kontinuierlich spürbar Performance aus den Anwendungen. Äußert sich ein Fehler durch relativ gleichmäßige Verzögerung (im Bereich von zwei bis drei Sekunden), haben Sie es in der Regel mit einem Fehler im DNS zu tun. DNS-Fehler gehören nach den ICMP-Fehlern (Nichterreichbarkeit von Anwendungen) zu den zweithäufigsten Problemen in Netzwerken. Da die DNS-Protokollanalyse ein komplettes Buch füllen kann, beschränken wir uns an dieser Stelle nur auf das grundsätzliche Verfahren.

Bleiben wir aber vorerst noch bei unserem Ping in Richtung des Servers. Der Server befindet sich nicht im gleichen Netzwerk wie der Client. Aus diesem Grund antwortet ein Router auf die ARP-Anfrage des Clients. Der Router wurde als Default Gateway auf dem Client konfiguriert. Der Router nimmt das ICMP Request-Paket auf, trägt als Ziel-MAC-Adresse die MAC-Adresse des nächsten Routers ein und schickt es anschließend in Richtung des Servers weiter. Der letzte Router in der Kette ermittelt per ARP die MAC-Adresse des Servers und schickt den ICMP-Request an den Server weiter. Der Server hört auf seine MAC-Adresse und empfängt das ICMP Request-Paket und retourniert dieses als ICMP Response-Paket zurück an den Router, der aus Sicht des Servers als Default Gateway agiert.

Lesen Sie im zweiten Teil des Fachartikels "Protokollanalyse im Netzwerk", warum die Fehlersuche in VoIP-Netzen oft viele unerwartete Probleme birgt und was Sie tun müssen, um auch hier zu einer aussagekräftigen Deutung der Messdaten zu gelangen.

  <<Vorherige Seite                Seite 3 von 3

Michael Engelhardt/dr/ln