Sergey Nivens - stock.adobe.com
Netzwerkanalyse: Traceroute-Schwächen bei Layer-2-Diagnose
Die Fehlersuche mit Traceroute kann schnell zu zeitintensiv werden. Ursache ist die unzureichende Erfassung von Netzwerkinformationen, meint Christian Köckert von NetBrain.
Im ersten Teil dieser Artikelserie zu den Schwächen von Traceroute haben wir bereits einige Einschränkungen behandelt, denen das Netzwerkanalyse-Tool Traceroute unterliegt. Es gibt jedoch noch weitere Faktoren, die es Netzwerkadministratoren erschweren, mit Traceroute sinnvolle Ergebnisse zu erzielen.
Wenn Traceroute den Pfad zu einem Ziel ermittelt hat, sind längst noch nicht die Details zu einem oder mehreren Hops bekannt. Der Nutzer kommt bei Telnet-/SSH-Verbindungen somit leider nicht an einer expliziten Anmeldung bei den jeweiligen Geräten vorbei.
Traceroute meldet lediglich die IP-Adresse der Schnittstelle zurück – was bei der Anmeldung an das Gerät nichts nützt: Um den Anmeldevorgang erfolgreich abzuschließen, muss nämlich außerdem die Management-IP-Adresse bekannt sein.
Telnet kann, für durch Traceroute erkannte Schnittstellen, daher nicht verwendet werden. Um eine Managementschnittstelle zu ermitteln, müsste man eine manuelle Abfrage durchführen, was jedoch ohne DNS-Auflösung nicht funktioniert. In der Praxis ist bei einem Netzwerkproblem jede Sekunde kostbar. Daher fehlt in so einer Situation einfach die Zeit für diese manuellen Schritte.
Keine Layer-2-Hops
Da Traceroute den TTL-Wert eines IP-Pakets je Hop um eins subtrahiert (siehe Teil 1), sendet es beim Erreichen des Wertes null eine ICMP-Nachricht über den Ablauf der TTL.
Die Reduzierung des TTL-Werts um eins wird allerdings nur bei Layer-3-Geräten durchgeführt, nicht jedoch bei Layer-2-Geräten. Aus diesem Grund wird ein Layer-2-Weg nicht transparent. Dennoch nutzen Rechenzentren häufig einen Layer-2-Switch für die Aggregation von Endstationen oder besitzen eine Layer-2-Verteilungsebene vor Core-Routern. Ein intransparentes Ergebnis ist die Folge.
„In der Praxis ist bei einem Netzwerkproblem jede Sekunde kostbar. Daher fehlt in so einer Situation einfach die Zeit für diese manuellen Schritte.“
Christian Köckert, NetBrain Technologies
Hinzukommt, dass die manuelle Level-2-Pfadanalyse auf MAC-Zuordnung und NDP-Informationen (Neighbor Discovery Protocol) beruht.
Daher ist eine Dokumentation nur sinnvoll, wenn sie den aktuellen Stand widerspiegelt und ermöglicht, MAC-Ausgangsports ohne NDP zu erkennen. Zudem müssten vom aktiven Gerät abgehende Trunks bestimmt werden, beziehungsweise diese Prozesse solange wiederholt werden, bis der erste Router erreicht wird.
Zeitintensive Fehleranalyse
Da Traceroute Layer-2-Informationen nicht anzeigt, ist diese Vorgehensweise extrem zeitintensiv und erschwert die Fehleranalyse erheblich. Auch hier können kommerzielle Lösungen eine bessere Alternative sein, da sie gegebenenfalls die Layer-2-Hops darstellen und zusätzlich den Analyseprozess automatisiert durchführen.
Über den Autor:
Christian Köckert ist Technical Lead Pre-Sales bei NetBrain, einem Anbieter von Produkten für Netzwerkautomatisierung. NetBrains adaptive Netzwerkautomatisierungsplattform bietet Transparenz in hybriden Netzwerken und ermöglicht die Automatisierung von Schlüsselaufgaben in den IT-Workflows.
Mit dem Dynamic Path (A/B Path) Calculator hat Netbrain auch eine Alternative zu Traceroute im Programm. A-B Path ist eine Funktion, die vor allem in Plattformen zur Netzwerkautomatisierung enthalten ist und dort den gesuchten Pfad visuell in einer dynamischen Netzwerkkarte abbilden kann.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
