Go back

Grenzen von Traceroute

April 1, 2020

Hier stoßen IT-Experten auf Grenzen

Eines der am häufigsten verwendeten Tools bei der Problemdiagnose ist zweifellos Traceroute. So hilfreich dieses Tool sein mag, es hat auch einige Nachteile. Aber bevor wir uns mit den Nachteilen beschäftigen, wollen wir uns Traceroute zunächst einmal näher ansehen.

Wie funktioniert Traceroute?

Der Ausgangsrechner (SRC) sendet in der Regel drei Testpakete an die IP-Zieladresse, beginnend mit einem Time-to-Live-Wert (TTL) von 1. Fälschlicherweise wird oft davon ausgegangen, dass dafür immer ein ICMP-Testpaket dient. Tatsächlich gibt jedoch das Traceroute-Ausgangsgerät das Protokoll vor. Windows-Betriebssysteme verwenden häufig ICMP, während Unix- und Routing-Geräte eher UDP-Nachrichten an vorübergehend geöffnete Ports (Ports größer als 1024, die von DNS-, SMTP-, Web- und ähnlichen Diensten genutzt werden) senden.

Nach Empfang des Testpakets bei jedem Layer-3-Gerät wird die TTL um eins reduziert. Beim TTL-Wert 0 gibt das Empfängergerät über die Schnittstelle, die das Paket empfangen hat, die ICMP-Nachricht „TTL expired“ aus. Auf diese Weise kennt Traceroute jeden Hop auf dem Pfad.

In der unteren Abbildung sind 172.16.2.1 und 10.3.2.2 die Adressen, die bei den Traceroute-Ergebnissen zurückgegeben werden.

Grenzen von Traceroute

Nachteile von Traceroute:

1. Problem:

Asymmetrische Pfade sind nicht einfach sichtbar. Nur A-zu-B wird standardmäßig gemeldet. Für B-zu-A muss Traceroute ein weiteres Mal vom anderen Ende ausgeführt werden, um den vollständigen Pfad zu kennen.

Asymmetrisches Routing ist in heutigen Netzwerken gang und gäbe. Neben der Fülle an ECMP-Übertragungen (Equal Cost Multi-Path) gibt es auch UCMP-Routing-Protokolle (Unequal Cost Multi-Path). Abhängig vom Hashing-Algorithmus läuft der Datenverkehr wahrscheinlich in jede Richtung auf einem anderen Pfad. Diese unterschiedlichen Pfade lassen sich mit einem einzigen Befehl nur schwer erkennen. Entsprechend problematisch ist auch die Bestimmung, wo genau eine spürbare Verzögerung auftritt.

Grenzen von Traceroute 2

Wie Sie oben sehen, springt der Delay-Wert an einem bestimmten Hop. Unklar bleibt aber, wo die Verzögerung konkret erfolgt: auf dem Hin- oder auf dem Rückweg?

2. Problem:

Nur die Geräte sind bekannt, nicht aber die Schnittstellen. Dazu sind zusätzliche Abfragen notwendig.

Bei der oben gezeigten Traceroute sind nur zwei Informationen bekannt: Hostname/IP und Verzögerungswert. Wer jetzt Hop 6 untersuchen will, muss eine Telnet/SSH-Verbindung zum Router aufbauen und herausfinden, welche Schnittstelle diese IP-Adresse hatte (ich würde für so etwas „show ip route 129.259.2.41“ verwenden, aber Sie könnten es auch mit „show ip interface“ probieren und die Ausgabe an einen Parser umleiten, z. B. „show ip interface brief | in 129.150.2.41“). Um nun die (abgehende) Egress-Schnittstelle zu bestimmen, wäre eine zweite Abfrage notwendig (z. B. „show ip route 192.41.37.40“).

3. Problem:

Traceroute basiert auf ICMP Messaging, das manchmal eine größere Verzögerung meldet, als beim Traffic tatsächlich vorliegt. Das liegt daran, dass ICMP auf dem „langsamen Pfad“ eines Gerätes verarbeitet wird und nicht auf dem „schnellen Pfad“, der zum Weiterleiten von Daten dient, die den Router passieren.

Dieser langsame Pfad lässt sich am einfachsten zusammenfassen, wenn der Router den Paketinhalt verarbeiten muss. Praktisch jedes Paket, das an ein Gerät gesendet wird, wird auf diese Weise verarbeitet. Neuere Router nutzen interne Mechanismen, um bei der Paketverarbeitung Prioritäten zu setzen, was das Problem jedoch nur noch verschlimmert: Protokoll-Updates werden vor ICMP-Nachrichten geroutet. Wie bereits erwähnt verwenden die meisten Systeme UDP-Nachrichten. Die Generierung der ICMP-Nachricht „TTL expired“ besitzt jedoch niedrigere Priorität, sodass der Antwortpfad eine ICMP-Nachricht sein wird, was aber die gemeldeten Verzögerungswerte problematischer erscheinen lässt, als sie tatsächlich sind.

4. Problem:

Traceroute liefert statischen Text, der als konkrete Handlungsanweisung kaum taugt.

Wir kennen jetzt also den Pfad zu einem bestimmten Ziel. Aber was ist, wenn wir genauere Details zu einem oder mehreren Hops auf diesem Pfad haben möchten? Bei Telnet/SSH-Verbindungen muss der Benutzer sich bei diesen Geräten anmelden. Nur die IP-Adresse der Schnittstelle ist in der Traceroute-Antwort enthalten. Dies kann in vielen Netzwerken zum Problem werden, da die Benutzer aus Sicherheitsgründen eine Telnet/ SSH-Verbindung mit der Management-IP-Adresse aufbauen müssen. Telnet könnte für Schnittstellen, die Traceroute erkannt hat, blockiert sein. Dann wäre irgendeine Art von manueller Abfrage notwendig, um die Management-Schnittstelle eines Geräts mit dieser Schnittstellen-Adresse herauszufinden. Ohne DNS-Auflösung dürfte das nahezu unmöglich sein. Und bei einem Ausfall zählt jede Sekunde.

5. Problem:

Equal-Cost-Pfade werden nicht dargestellt. Nur der tatsächliche Pfad, den Traceroute nimmt, wird gemeldet.

Wie zuvor erwähnt sind ECMP- und UCMP-Routen heutzutage in vielen Netzwerken üblich. Traceroute erkennt aber nur den Pfad, der für die Testnachrichten verwendet wurde. Da die meisten Traceroute- Implementierungen drei Testpakete mit verschiedenen UDP-Zielports senden, können in einer ECMP-Umgebung für jeden Hop bis zu drei verschiedene IP-Adressen gemeldet werden. Nur mit größerem Aufwand lässt sich dann nachvollziehen, welche Antwort zu welchem Pfad gehört.

Grenzen von Traceroute 3

6. Problem:

Traceroute meldet keine Layer-2-Hops.

Wie wir wissen, funktiert Traceroute, indem der TTL-Wert in einem IP-Paket um eins reduziert wird, sodass bei 0 eine ICMP-Nachricht über den Ablauf der TTL („TTL expired“) generiert wird. Diese Reduzierung erfolgt nur bei Layer-3-Geräten. Folglich mangelt es an Transparenz und aus den Ergebnissen ist nur schwer ersichtlich, welcher Layer-2-Pfad genommen wurde. In Unternehmen und Rechenzentren gibt es meistens irgendeine Form von Layer-2-Access-Switch, der zum Aggregieren der Endstationen dient. Einige Netzwerke verwenden sogar eine Layer-2-Verteilungsebene, bevor der Traffic einen Core-Router erreicht. Diese Ebene führt die erste Layer-3-Routing-Funktion durch, die bei einer Traceroute-Abfrage erkannt werden kann. Zeigt das Traceroute-Ergebnis einen Paketverlust, könnte dies am falschen Hashing für einen Layer-2-Port-Kanal oder eine Link Aggregation Group (LAG) liegen. Aber auch Probleme mit dem Spanning Tree, einer Duplex-Konfiguration bei einem Switch oder andere Probleme sind denkbar, die sich jedoch nur durch Überprüfen der Layer-2-Elemente auf dem Pfad entdecken lassen. Um hier Genaueres zu erfahren, sind folgende Schritte notwendig:

1. Bestimmen der MAC-Adresse des Ausgangsgeräts im Layer-2-Segment (Überprüfen der ARP-Tabelle im Router oder Ausgangsgerät)

2. Nachschlagen in der Dokumentation, um die verwendeten Switches herauszufinden

3. Anmelden bei jedem erdenklichen Pfad und Überprüfen der MAC-Tabellen für die jeweilige MAC-Adresse

4. Ausführen von Befehlen, um die Leistung und Konfiguration zu überprüfen

5. Bestimmen der abgehenden Trunks vom aktiven Gerät

6. Anmelden beim nächsten Layer-2-Gerät und Wiederholen des Prozesses, bis der erste Router erreicht ist

Diese Vorgehensweise kann äußerst zeitaufwendig sein, insbesondere wenn CDP/LLDP nicht im Netzwerk aktiviert ist oder die Dokumentation veraltet ist.

7. Problem:

Bei Traceroute fehlen historische Daten.

Traceroute liefert ausschließlich eine Momentaufnahme des aktuellen Status. Es gibt keine Möglichkeit festzustellen, welcher Pfad genommen wurde, als beim Traffic alles rund lief z. B. am Vortag). Nehmen wir die folgende Traceroute: Hier ließe sich das Problem leichter einkreisen, wenn wir wüssten, welcher Hop 4 vor Auftreten des Problems verwendet wurde.

Grenzen von Traceroute 4

Aus Erfahrung weiß ich, dass viele Techniker das Ergebnis, das der obige Befehl liefert, so interpretieren, dass Hop 3 das Problem sei. Das ist jedoch häufig nicht der Fall. Zuerst sollte man sich am Hop 3 bei dem Gerät anmelden und überprüfen, ob im Gerät ein Routing-Eintrag zu dem Ziel vorhanden ist. Wenn ja, verursacht häufig das Gerät im nächsten Hop des Routing-Eintrags das Problem. Um auf Nummer sicher zu gehen, sollte auch die Egress-Schnittstelle für das Routing zum nächsten Hop überprüft werden, damit Sie die Schnittstellenleistung und die ACL-Konfiguration kennen.

8. Problem:

Traceroute produziert kaum verständliche Fehlermeldungen.

Bei näherer Betrachtung von Traceroute-Ausgaben stoße ich immer auf Zeichen, die mich verwundern. Die folgende Tabelle stammt aus einer Traceroute-Implementierung von Cisco. Auf den ersten Blick mag das alles verständlich wirken. Aber wenn man genau wissen will, was vor sich geht, kommt man meistens um weitere Überprüfungen nicht herum.

Grenzen von Traceroute 5

Beispielsweise liefert mir eine Traceroute-Antwort den Buchstaben A, was bedeutet, dass wahrscheinlich eine ACL Traceroute den Zugriff verwehrt – nur um welche Zugriffsliste handelt es sich konkret? Um das festzustellen, muss ich mich bei dem Router anmelden, herausfinden, über welche Schnittstelle das Paket eingegangen ist, die Konfiguration überprüfen und mir die ACL genauer ansehen – wenn ich sie endlich gefunden habe. Das kann ein langwieriger Prozess sein und da bei Problemdiagnosen jede Minute zählt, wäre es hilfreich, schneller an diese Informationen zu kommen.

Meiner Erfahrung nach gibt es solche Fehlermeldungen nur von Ingress-basierten Schnittstellen. Wurde ein Paket problemlos empfangen und dann zum nächsten Hop auf dem Pfad weitergeleitet – und sollte es eine ACL für den Egress-Port geben –, lautet das Ergebnis für den nächsten Hop einfach: * * *. Das bedeutet, dass weitere Schritte notwendig sind, um sicherzustellen, dass die Egress-Schnittstelle bekannt ist und jede ACL für diesen Port ebenfalls bestätigt wird.

Was ist die Lösung?

Der A/B Path Calculator von NetBrain wurde eigens für diese Problematik entwickelt und ermöglicht die dynamische Abbildung des Pfads zwischen zwei Netzwerk-Punkten. Diese Funktion berücksichtigt bei der Abbildung Technologien wie Firewalls oder den Lastenausgleich sowie erweiterte Protokolle (Routing, ACL, PBR, VRF, NAT usw.).

Grenzen von Traceroute 6

Abbildung trotz Firewalls und Lastverteiler, mit ACL und Virtual-IP Translation

A/B Path Calculator in der Praxis – drei Beispiele

1. Praxisbeispiel:

Abbilden einer langsamen Anwendung – Eine Webanwendung zwischen Boston und Los Angeles läuft nur langsam.

Grenzen von Traceroute Praxisbeispiel 1

2. Praxisbeispiel:

Abbilden des VoIP-Verkehrsflusses – Bei Telefonaten zwischen Boston und San Francisco wird die Sprache manchmal zeitverzögert übertragen (Jitter).

Grenzen von Traceroute Praxisbeispiel 2

3. Praxisbeispiel:

Abbilden eines DDoS-Angriffs – Ein bösartiger Host speist DDoS Traffic in das Netzwerk. Woher kommt der Traffic und was sind die Folgen? Mit NetFlow können Sie die Netzwerk-Elemente mit dem höchsten Traffic- Aufkommen identifizieren und so den Pfad abbilden:

Grenzen von Traceroute Praxisbeispiel 3

Jetzt PDF herunterladen: Grenzen von Traceroute

Related