Trace-Route im MPLS-Netzwerk

Download-Optionen

  • PDF     (493.2 KB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (439.4 KB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (463.4 KB)
    Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:25. September 2018
Dokument-ID:200510

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Einführung

Dieses Dokument beschreibt das ICMP-Traceroutenverhalten (Internet Control Message Protocol) im Multiprotocol Label Switching (MPLS)-Netzwerk und einen schnellen Vergleich mit LSP Traceroute.

Hintergrundinformationen

In einer IP-Umgebung wird jeder Knoten, der ein Paket empfängt und die Time To Live (TTL) abläuft, voraussichtlich die ICMP-Fehlermeldung "TTL Exceeded" (TTL Exceeded (TTL)) generieren (Type=11, Code=0) und es an die Paketquellen-Adresse senden. Dieses Konzept wird verwendet, um den IP-Pfad von der Quelle zum Ziel zu verfolgen, indem das UDP-Paket mit TTL sequenziell ab 1 gesendet wird. Hierbei ist zu beachten, dass diese Funktionalität folgende grundlegende Anforderungen erfüllt:

  • Die Quelladresse des Pakets ist über die Transit-Knoten erreichbar.
  • ICMP wird nicht entlang des Pfads gefiltert

In MPLS-Umgebungen kann es vorkommen, dass ein Transit-Provider-LSR nicht immer auf die Quelladresse zugreifen kann und eine Verbesserung für die ICMP-Verarbeitung in der MPLS-Domäne erforderlich ist. 

ICMP-Traceroute im MPLS-Netzwerk

Das Standardverhalten eines beliebigen LSR beim Empfang eines Pakets mit TTL=1 auf oberster Bezeichnung folgt dem traditionellen IP-Verhalten, das darin besteht, das Paket zu verwerfen und eine ICMP-Fehlermeldung auszulösen. Um die ICMP-Nachricht an die Quelle weiterzuleiten, führt der LSR Folgendes durch:

  • Puffern des Label-Stacks aus dem eingehenden Paket (das Paket, das mit TTL=1 empfangen wurde)
  • Generieren Sie eine ICMP-Fehlermeldung, bei der Quelle als eigene Adresse und Ziel als Quelladresse aus dem empfangenen Paket angegeben wird.
  • Anfügen aller Labels aus dem unteren Teil des Label-Stacks (die zuvor in Schritt 1 gepuffert wurde) mit TTL=255, mit Ausnahme des oberen Labels.
  • Holen Sie das oberste Label aus dem gepufferten Label-Stack, und führen Sie eine lokale LFIB-Suche durch, um das Label zu ersetzen und den zugehörigen nächsten Hop zu ersetzen.
  • Hängen Sie die neue Bezeichnung mit TTL=255 an die Spitze des Stacks an, und senden Sie sie weiter.

Bei diesem Ansatz wird die ICMP-Fehlermeldung vom Transit-LSR zum Ausgangs-LER und dann zurück zum Eingangs-LER zur eigentlichen Quelle übertragen.

Vom PE zum Remote-PE ausgelöster ICMP-Trace

Das folgende einfache Beispiel erklärt das Verhalten, wenn die ICMP-Ablaufverfolgung vom PE zum Remote-PE innerhalb derselben MPLS-Domäne ausgelöst wird:

200510-Trace-route-in-MPLS-network-00.jpeg

Wenn in dieser Topologie ICMP-Traceroute von R2 bis 10.1.4.4 ausgelöst wird, wird das erste Paket mit TTL von 1 gesendet. R3 beim Empfang des Pakets senkt die TTL auf 0 und löst einen ICMP-Erzeugungsmechanismus aus.

200510-Trace-route-in-MPLS-network-01.jpeg

R3 puffert den Label-Stack und generiert eine ICMP-Fehlermeldung. Außerdem wird der eingehende Label-Stack aus dem Puffer in die ICMP-Payload aufgenommen. Darüber hinaus wird der IP-Header mit der Quelladresse aus der Eingangsschnittstelle des bezeichneten Pakets, der Zieladresse als Quelle des bezeichneten Pakets, gefüllt. Die TTL ist auf 255 festgelegt. Der Label-Stack wird nun aus dem Puffer entfernt und die LFIB-Tabelle zur Weiterleitungsaktion auf dem obersten Label aufgerufen. In dieser Topologie beträgt der empfangene Label-Stack 17. Beim Durchführen einer Suche in der LFIB-Tabelle wird Label 17 durch Label 16 ersetzt und an die Next-Hop-R6 weitergeleitet. R6 wiederum führt das oberste Label aus und leitet es an R4 weiter, das das Paket zurück an R2 weiterleitet.

Wie bereits in der Traceroute-Ausgabe auf R2 erwähnt, wird das eingehende Label von jedem Hop entlang des Pfads aufgelistet.

ICMP-Trace vom CE zum Remote-CE ausgelöst

Das folgende einfache Beispiel erklärt das Verhalten, wenn die ICMP-Ablaufverfolgung von CE zu Remote-CE über eine MPLS-Domäne ausgelöst wird:

200510-Trace-route-in-MPLS-network-02.jpeg

Wenn in dieser Topologie ICMP-Traceroute von R1 (CE) bis 192.168.5.5 (Remote-CE) ausgelöst wird, wird das erste Paket mit TTL von 1 gesendet. Dies ist ein normales IP-Paket, und R2 folgt daher dem traditionellen Verhalten, ICMP zu generieren und direkt an R1 zu senden. Das zweite Paket, das mit TTL=2 gesendet wird, läuft mit R3 ab.

200510-Trace-route-in-MPLS-network-03.jpeg

R3 puffert den Label-Stack und generiert eine ICMP-Fehlermeldung. Außerdem wird der eingehende Label-Stack aus dem Puffer in die ICMP-Payload aufgenommen. Darüber hinaus wird der IP-Header mit der Quelladresse aus der Eingangsschnittstelle des bezeichneten Pakets, der Zieladresse als Quelle des bezeichneten Pakets, gefüllt. Die TTL ist auf 255 festgelegt. Der Label-Stack wird nun aus dem Puffer entfernt und die LFIB-Tabelle zur Weiterleitungsaktion auf dem obersten Label aufgerufen. In der oben genannten Topologie ist der empfangene Label-Stack {17, 18}. Beim Durchführen einer Suche in der LFIB-Tabelle für das oberste Label werden 17 durch das Label 16 ersetzt und an die Next-Hop-R6 weitergeleitet. R6 wiederum führt das oberste Label an und leitet es an R4 weiter. R4 verwendet das VRF-Label, um die VRF-Instanz zu identifizieren und das Paket zurück an R1 weiterzuleiten.

Wie bereits in der Traceroute-Ausgabe auf R1 erwähnt, wird der eingehende Label-Stack von jedem Hop entlang des Pfads aufgelistet.

MPLS LSP-Traceroute im MPLS-Netzwerk

200510-Trace-route-in-MPLS-network-04.jpeg

Im Gegensatz zu ICMP-basierter Traceroute verwendet LSP Traceroute die in RFC 4379 definierten Maschinen. Dabei wird die IP/UDP-Kapselung verwendet, wobei die Zieladresse der Anforderung auf die Loopback-Adresse (Bereich 127.0.0.0/8) festgelegt ist. Es wird erwartet, dass LSP Ping innerhalb derselben MPLS-Domäne ausgelöst wird. Daher wird die Antwort direkt an den Initiator gesendet.

Wenn LSP-Traceroute ("traceroute mpls ipv4 <FEC>") von einem LSR ausgelöst wird, werden die Details zu dem zu validierenden FEC in einer TLV als "Target FEC Stack" (Ziel-FEC-Stack) in der MPLS-Echo-Anforderung aufgenommen. Diese Nachricht wird mit TTL im Label-Stack sequenziell ab 1 gesendet. Alle Transit-LSRs, die das Paket empfangen und bei denen die TTL abläuft, verarbeiten das IP-Paket, da es sich bei der Zieladresse um eine Loopback-Adresse handelt. und auf CPU für MPLS OAM-Verarbeitung.

Der Responder führt optional eine FEC-Validierung durch, indem er die Label aus dem Label-Stack der empfangenen MPLS-Echo-Anforderung- und FEC-Details von Target FEC Stack TLV abruft, um dies anhand der Informationen auf der lokalen Kontrollebene zu validieren. Im Falle einer Nachverfolgung enthält der Responder die Downstream-Informationen wie das Outgoing Label und die Downstream-Nachbaradresse usw. in einer TLV als Downstream Mapping (DSMAP) TLV. (DSMAP wird von DMAP veraltet, da es flexibler ist als DSMAP).

Vom PE zum Remote-PE ausgelöster LSP-Trace

200510-Trace-route-in-MPLS-network-05.jpeg

In dieser Topologie wird LSP trace von R2 ausgelöst, um den LSP auf das Präfix 10.1.4.4/32 zu validieren. Die TTL auf dem Label wird auf 1 festgelegt. R3 beim Empfang wird auf CPU für die OAM-Verarbeitung angewendet.

200510-Trace-route-in-MPLS-network-06.jpeg

R3 antwortet auf R2 mit MPLS-Echo-Antwort mit DSMAP TLV mit ausgehendem Label 16 und zusätzlichen Informationen wie Downstream-Nachbardetails. Im Gegensatz zu ICMP-Nachrichten wird die MPLS-Echo-Antwort direkt vom Responder R3 an Initiator R2 weitergeleitet.

Wie bereits in der Ausgabe des LSP-Traceroute auf R2 erwähnt, wird der ausgehende Label-Stack von jedem Hop entlang des Pfads aufgelistet. Dies unterscheidet sich von ICMP-basiertem Traceroute, bei dem das in der Ausgabe aufgeführte Label ein eingehender Label-Stack ist.

LSP-Trace ausgelöst vom CE zum Remote-CE

200510-Trace-route-in-MPLS-network-07.jpeg

Dies gilt für CSC-ähnliche Szenarien, in denen MPLS zwischen PE-CEs aktiviert ist. Es gibt zwei Herausforderungen bei der Ausführung der LSP-Ablaufverfolgung vom CE zum Remote-CE über die Carrier MPLS-Domäne:

  • Die Sprachdienstleister-Echo-Antwort wird direkt an den Initiator gesendet. Der Responder MUSS über die Erreichbarkeit zum Initiator verfügen. In der oben genannten Topologie ist R3 möglicherweise nicht auf R1 erreichbar, da er sich in der VRF-Instanz befindet.
  • Für jedes Label im Label-Stack sollten relevante FEC-Details zur Validierung im Target FEC-Stack enthalten sein. Der vom Initiator enthaltene FEC ist 1, während der PE zwei Labels drückt. In der oben genannten Topologie sendet R1 MPLS-Echo-Anforderung mit FEC={192.168.5.5/32} und fügt das Label 28 in den Stack ein. Da R2 das Label 28 mit {17, 27} ersetzt, erhält R3 das Request mit 2 Label im Stack, während 1 FEC in TLV die FEC Validierung verwirrt.

RFC6424 definiert das Konzept der "FEC Stack Change TLV" zur Behebung von Problem 2. Diese TLV wird in der Antwort mit der relevanten FEC als PUSH/POP enthalten sein, die von Initiator in nachfolgenden Echo Request aufgenommen werden kann.

Draft-ietf-mpls-lsp-ping-relais-reply definiert das Konzept für die Übertragung von Relay-Knoten-Adressenstapeln in TLV, das vom Responder verwendet werden kann, um die Antwort weiterzuleiten, obwohl der Initiator nicht erreichbar ist.

200510-Trace-route-in-MPLS-network-08.jpeg

Diese beiden Probleme werden derzeit in Cisco IOS® nicht unterstützt, sodass die LSP-Ablaufverfolgung vom CE zum Remote-CE nur den Eingangs-PE und den Remote-CE aufführt. Dies ist nur zur Vollständigkeit enthalten.

Zugehörige Informationen

TAC Authored

Beiträge von Cisco Ingenieuren

  • Nagendra Kumar Nainar
    Cisco TAC-Techniker

War dieses Dokument hilfreich?

FeedbackFeedback

Cisco kontaktieren