Inhalt

Einführung

Hintergrundinformationen

ICMP-Traceroute im MPLS-Netzwerk

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

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

MPLS LSP-Traceroute im MPLS-Netzwerk

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

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

Zugehörige Informationen

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:

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.

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:

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.

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

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

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.

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

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.

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

- RFC 3032

- RFC 4379

- RFC 6424