MPLS LSP Multipath-Nachverfolgung

Einleitung

MPLS LSP-Ping ist ein grundlegendes Tool zur Überprüfung der Integrität des Label Switched Path (LSP) zwischen Eingang und Ausgang.  In diesem Dokument wird die Interaktion von Multipath-Informationen zwischen Initiator und Responder in der LSP-Baumüberwachung erläutert. Ausführliche Informationen zu den verfügbaren Optionen für dieses Tool finden Sie in diesem Dokument.

Hintergrundinformationen

Diese Implementierung der MPLS EM-MPLS LSP Multipath Tree Trace-Funktion basiert auf RFC 4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures.

Durch Festlegen der IP-Zieladresse des Prüfpakets als Loopback-Adresse (127.x.x.x) kann die LSP-Baumstruktur-Nachverfolgung verwendet werden, um einen Fehler in LSP zu erkennen, indem verhindert wird, dass das Paket eine IP-Weiterleitung erhält. Bei End-to-End-Verbindungsproblemen ist es daher hilfreich, LSP-Ping als ersten Schritt zu verwenden, um LSP-Fehler zu vermeiden.

Bei Multipath-Szenarien kann es vorkommen, dass der LSP-Ping nicht immer dazu beiträgt, alle LSP-Fehler zu erkennen. Wie erwähnt, verwendet jeder Label Switch Router (LSR) beim Empfang eines bezeichneten Pakets, das über mehrere Ausgangsschnittstellen gesendet werden kann, bestimmte Schlüssel aus dem Paket und der Eingabe zum Hashing-Algorithmus, um die Ausgangsschnittstelle zu bestimmen. Abhängig vom Anbieter, der Hardware usw. kann eine der folgenden Optionen für das Hashing in Betracht gezogen werden:

1. Nur eingehender Labelstapel.
2. Eingehende Label-Stack- und IP-Header-Details (wenn die Nutzlast IP ist).
3. Details zu eingehendem Label-Stack, IP-Header und Transportheader

Normalerweise berücksichtigen Cisco Router eine Kombination aus Label-Stack und IP-Header, wenn der Stack eine Größe von kleiner oder gleich 3 hat (mit IP als Nutzlast).

Nehmen wir folgende Topologie an.

R1-R7 sind Router. In der oben beschriebenen Topologie gibt es 3 Equal Cost Multi Path (ECMP)-Routen von R1 nach R5 wie unten.

PFAD 1: R1-R2-R3-R4-R5

PFAD2: R1-R2-R6-R4-R5

PFAD3: R1-R2-R6-R7-R5

Angenommen, es liegt ein Problem zwischen R6 und R7 vor (z. B. ein defektes Label Distribution Protocol (LDP) oder Label-Fehlprogrammierung usw.), das dazu führt, dass der Datenverkehr von R1 nach R5 über PATH3 fällt. Wenn LSP Ping von R1 PATH1 oder PATH2 verwendet, gehen Sie möglicherweise davon aus, dass der Pfad zwischen R1 und R5 in Ordnung ist.

LSP-Ping ermöglicht das Festlegen der IP-Zieladresse auf eine Adresse aus dem Bereich 127.0.0.0/8. Eine einfache Möglichkeit besteht darin, manuell zu versuchen, mehrere Ping-Pakete mit unterschiedlichen Zieladressen zu senden. Es gibt jedoch keine Garantie, dass alle möglichen ECMP-Pfade validiert werden. Sie benötigen eine Methode, die alle möglichen Pfade zwischen Quelle und Ziel abfragt und validiert. LSP Multipath tree trace nutzt die in Abschnitt 3.3.1 von RFC4379 definierte "Multipath Information Encoding" und unterstützt Sie bei der Validierung aller ECMP-Pfade.

LSP Tree Trace - Funktionsweise

Ein regulärer MPLS-Ping oder eine Traceroute können darauf hindeuten, dass kein Fehler auftritt, je nachdem, wie die Transit-Router die Pakete über ECMP gemeinsam nutzen. Die LSP-Baumstrukturverfolgung bietet jedoch eine bessere Methode, um zu überprüfen, ob alle Pfade tatsächlich funktionieren.  

Bei der LSP-Baumstruktur-Nachverfolgung sendet der Initiator-Router eine MPLS-Echo-Anforderung an jeden Hop, indem er die TTL im obersten Label schrittweise (beginnend bei 1) festlegt. Die Echo-Anforderung überträgt Multipath Information TLV, das einen IP-Adressbereich (innerhalb des Bereichs 127.0.0.0/8) oder einen Entropieetikettenbereich überträgt. Derzeit unterstützen Cisco Geräte die IP-Zieloption. Daher wird das Beispiel im Einzelnen mit dem IP-Adressbereich beschrieben.

Jeder Transit-LSR, der das Anforderungspaket empfängt, antwortet mit allen ausgehenden ECMP-Schnittstellen und ordnet der Anforderung für jede Schnittstelle einen IP-Adressbereich (oder ein Entropiekennzeichen) zu.

LSP Tree Trace - Detailliertes Beispiel

Nehmen wir zum Beispiel die folgende Topologie an.

Der Einfachheit halber wird in diesem Beispiel der Adressbereich 127.0.0.0-127.0.0.200 verwendet. Hier sind die Details der Schritte in einer LSP-Baumstruktur-Nachverfolgung.

1) Initiator (R1) sendet die Echoanfrage mit den folgenden Details:

• IP-Ziel: 127.0.0.0
• Multipath Information TLV mit dem Adressbereich 127.0.0.0 bis 127.0.0.200.
• Die TTL des obersten Labels wird auf 1 festgelegt.

2) R2 antwortet bei Erhalt derselben mit Multipath Information (Multipath-Informationen) für jede Ausgangsschnittstelle. In diesem Beispiel antwortet er wie folgt:

• Wenn das IP-Ziel innerhalb von 127.0.0.0 bis 127.0.0.100 liegt, wird das Paket an R3 gesendet.
• Wenn das IP-Ziel innerhalb von 127.0.0.101 bis 127.0.0.200 liegt, wird das Paket an R6 gesendet.

3) R1 erkennt, dass es 2 mögliche ECMP-Pfade gibt und muss daher 2 Echoanfragen mit TTL auf 2 senden. Aus verschiedenen Tests wurde beobachtet, dass der Initiator immer mit 1 Pfad endet, bevor er zum nächsten weitergeht. (Dies könnte jedoch für eine bestimmte Implementierung gelten.)

4) R1 sendet jetzt eine Echoanfrage mit den folgenden Details:

• IP-Ziel: 127.0.0.0
• Multipath Information TLV mit dem Adressbereich 127.0.0.0 bis 127.0.0.100.
• Die TTL des obersten Labels wird auf 2 festgelegt.

5) R2 leitet das Paket an R3 weiter (die Zieladresse lautet 127.0.0.0). R3 antwortet beim Empfang derselben mit denselben Multipath-Informationen, da es nur eine Ausgangsschnittstelle gibt.

Dasselbe gilt, bis es R5 erreicht.

6) Sobald die PATH1-Ablaufverfolgung abgeschlossen ist (nachdem die Antwort vom Ausgang empfangen wurde), fragt der Initiator jetzt PATH2 ab. Senden Sie dazu die Echoanfrage mit den folgenden Details:

• IP-Ziel: 127.0.0.101
• Multipath Information TLV mit dem Adressbereich 127.0.0.101 bis 127.0.0.200
• Die TTL des obersten Labels wurde auf 2 festgelegt.

7) R2 leitet das Paket an R6 weiter (die Zieladresse lautet 127.0.0.101). R6 antwortet bei Erhalt derselben mit Multipath-Informationen wie unten:

• Wenn das IP-Ziel innerhalb von 127.0.0.101 bis 127.0.0.150 liegt, wird das Paket an R4 gesendet.
• Wenn das IP-Ziel innerhalb von 127.0.0.151 bis 127.0.0.200 liegt, wird das Paket an R7 gesendet.

8) R1 erkennt, dass es einen weiteren ECMP-Pfad gibt, der die insgesamt möglichen Pfade als 3 definiert. R1 fährt mit der Abfrage von PATH2 fort, indem die nächste Echoanfrage mit den folgenden Details gesendet wird:

• IP-Ziel: 127.0.0.101
• Multipath Information TLV mit dem Adressbereich 127.0.0.101 bis 127.0.0.150
• Die TTL des obersten Labels wurde auf 3 festgelegt.

9) R2 leitet das Paket an R6 weiter (das Ziel ist 127.0.0.101) und R6 leitet es an R4 weiter (das Ziel ist 127.0.0.101). R4 hat keinen ECMP-Pfad und antwortet daher mit den gleichen Multipath-Informationen. Das nächste Paket erreicht Ausgang R5.

10) Da die PATH2-Ablaufverfolgung abgeschlossen ist, setzt R1 die Abfrage für PATH3 fort. Senden Sie dazu die Echoanfrage mit den folgenden Details:

• IP-Ziel: 127.0.0.151
• Multipath Information TLV mit dem Adressbereich 127.0.0.151 bis 127.0.0.200
• Die TTL des obersten Labels wurde auf 3 festgelegt.

11) R2 leitet das Paket an R6 weiter, das es wiederum an R7 weiterleitet. R7 antwortet mit dem gleichen Multipath Information TLV. Das nächste Paket erreicht den Egress-Router R5.

Nach Abschluss dieser Schritte enthält R1 folgende Details:

                            

Durch die Verwendung der Zieladresse innerhalb der Bereiche 127.0.0.0 und 127.0.0.100 wird die Paketweiterleitung über PATH1 beeinflusst, während die Verwendung der Adresse aus anderen Bereichen die Weiterleitung des Pakets über die jeweiligen Pfade beeinflusst.

12) Der Initiator sendet jetzt 3 Echo-Anforderungspakete, deren TTL auf 255 festgelegt ist, und wählt die Adresse aus jedem Bereich aus, sodass alle Pfade durchgängig validiert werden.

Der für die ECMP-Ablaufverfolgung zu verwendende Befehl lautet traceroute mpls multipath ipv4 <prefix> <mask>. Nachfolgend finden Sie eine Beispielausgabe.

R1#traceroute mpls multipath ipv4 10.1.5.5 255.255.255.255

Starting LSP Multipath Traceroute for 10.1.5.5/32
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
LLL!
Path 0 found,
output interface Et0/0.12 nexthop 10.1.12.2
source 10.1.12.1 destination 127.0.0.4
LL!
Path 1 found,
output interface Et0/0.12 nexthop 10.1.12.2
source 10.1.12.1 destination 127.0.0.2
L!
Path 2 found,
output interface Et0/0.12 nexthop 10.1.12.2
source 10.1.12.1 destination 127.0.0.0
Paths (found/broken/unexplored) (3/0/0)
Echo Request (sent/fail) (9/0)
Echo Reply (received/timeout) (9/0)
Total Time Elapsed 27 ms

Beachten Sie, dass die obige Ausgabe zeigt, dass es 3 Pfade gibt und alle Pfade gut funktionieren. Wenn Sie den ausführlichen Knopf oben verwenden, werden alle Hops wie folgt aufgelistet:

R1#traceroute mpls multipath ipv4 10.1.5.5 255.255.255.255 verbose

Starting LSP Multipath Traceroute for 10.1.5.5/32
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
LLL!
Path 0 found,
output interface Et0/0.12 nexthop 10.1.12.2
source 10.1.12.1 destination 127.0.0.4
0 10.1.12.1 10.1.12.2 MRU 1500 [Labels: 22 Exp: 0] multipaths 0
L 1 10.1.12.2 10.1.23.3 MRU 1500 [Labels: 23 Exp: 0] ret code 8 multipaths 2
L 2 10.1.23.3 10.1.34.4 MRU 1500 [Labels: 22 Exp: 0] ret code 8 multipaths 1
L 3 10.1.34.4 10.1.45.5 MRU 1500 [Labels: implicit-null Exp: 0] ret code 8 multipaths 1
! 4 10.1.45.5, ret code 3 multipaths 0
LL!
Path 1 found,
output interface Et0/0.12 nexthop 10.1.12.2
source 10.1.12.1 destination 127.0.0.2
0 10.1.12.1 10.1.12.2 MRU 1500 [Labels: 22 Exp: 0] multipaths 0
L 1 10.1.12.2 10.1.26.6 MRU 1500 [Labels: 16 Exp: 0] ret code 8 multipaths 2
L 2 10.1.26.6 10.1.46.4 MRU 1500 [Labels: 22 Exp: 0] ret code 8 multipaths 2
L 3 10.1.46.4 10.1.45.5 MRU 1500 [Labels: implicit-null Exp: 0] ret code 8 multipaths 1
! 4 10.1.45.5, ret code 3 multipaths 0
L!
Path 2 found,
output interface Et0/0.12 nexthop 10.1.12.2
source 10.1.12.1 destination 127.0.0.0
0 10.1.12.1 10.1.12.2 MRU 1500 [Labels: 22 Exp: 0] multipaths 0
L 1 10.1.12.2 10.1.26.6 MRU 1500 [Labels: 16 Exp: 0] ret code 8 multipaths 2
L 2 10.1.26.6 10.1.67.7 MRU 1500 [Labels: 17 Exp: 0] ret code 8 multipaths 2
L 3 10.1.67.7 10.1.57.5 MRU 1500 [Labels: implicit-null Exp: 0] ret code 8 multipaths 1
! 4 10.1.57.5, ret code 3 multipaths 0
Paths (found/broken/unexplored) (3/0/0)
Echo Request (sent/fail) (9/0)
Echo Reply (received/timeout) (9/0)
Total Time Elapsed 29 ms