MPLS LSP Multipath Trace

Introduction

MPLS LSP Ping est un outil de base utilisé pour valider l'état du chemin LSP (Label Switched Path) entre l'entrée et la sortie.  Ce document vise à expliquer l'interaction des informations de trajets multiples entre l'initiateur et le répondeur dans le suivi de l'arborescence LSP. Pour connaître les options détaillées disponibles pour cet outil, il serait utile de consulter ce document.

Informations générales

Cette mise en oeuvre de la fonctionnalité MPLS EM—MPLS LSP Multipath Tree Trace est basée sur la norme RFC 4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures.

En définissant l'adresse IP de destination du paquet de sonde comme adresse de bouclage (127.x.x.x), le suivi de l'arborescence LSP peut être utilisé pour détecter une défaillance dans LSP en évitant que le paquet ne soit routé IP. Par conséquent, en cas de problème de connectivité de bout en bout, il est utile d’utiliser la commande Ping LSP comme première étape pour éliminer toute défaillance LSP.

Dans le cas de scénarios à trajets multiples, la requête ping LSP peut ne pas toujours aider à identifier toutes les pannes LSP. Comme on peut le constater, tout routeur à commutation d’étiquettes (LSR), lorsqu’il reçoit un paquet étiqueté qui peut être envoyé par plusieurs interfaces de sortie, utilise certaines clés du paquet et les entrées de l’algorithme de hachage pour décider de l’interface de sortie. Selon le fournisseur, le matériel, etc., l'une des options ci-dessous peut être prise en compte pour le hachage :

1. Pile d'étiquettes entrantes seule.
2. Pile d'étiquettes entrantes et détails d'en-tête IP (si la charge utile est IP).
3. Pile d'étiquettes entrantes, en-tête IP et en-tête de transport.

Normalement, les routeurs Cisco considèrent une combinaison de pile d'étiquettes et d'en-tête IP si la taille de la pile est inférieure ou égale à 3 (avec IP comme charge utile).

Supposez la topologie suivante.

R1 à R7 sont des routeurs. Dans la topologie ci-dessus, il existe 3 routes ECMP (equal cost multi path) de R1 à R5 comme ci-dessous,

CHEMIN1 : R1-R2-R3-R4-R5

CHEMIN2 : R1-R2-R6-R4-R5

CHEMIN3 : R1-R2-R6-R7-R5

Supposons qu'un problème survient entre R6 et R7 (comme un protocole LDP (Label Distribution Protocol) rompu ou une erreur de programmation d'étiquette, etc.) provoquant l'abandon du trafic de R1 à R5 via PATH3. Si la requête ping LSP de R1 emprunte PATH1 ou PATH2, vous pouvez finir par supposer que le chemin entre R1 et R5 est correct.

La commande Ping LSP permet de définir l'adresse IP de destination comme une adresse quelconque de la plage 127.0.0.0/8. Bien qu'une option simple consiste à essayer manuellement d'envoyer plusieurs paquets ping avec une adresse de destination différente, il n'y a aucune garantie que tous les chemins ECMP possibles seront validés. Vous avez besoin d'une méthode qui interroge et valide tous les chemins possibles entre la source et la destination. Le suivi de l'arborescence multichemin LSP tire parti du « Multipath Information Encoding » défini dans la section 3.3.1 de la RFC4379 et vous aide à valider tous les chemins ECMP.

Trace de l'arborescence LSP - Fonctionnement

Une requête ping ou traceroute MPLS régulière peut indiquer qu'il n'y a pas d'échec selon la façon dont les routeurs de transit partagent la charge des paquets sur ECMP, cependant la trace de l'arborescence LSP fournit une meilleure méthode pour valider que tous les chemins fonctionnent réellement.  

Dans l’arborescence LSP, le routeur initiateur envoie une requête d’écho MPLS à chaque saut en définissant la durée de vie dans l’étiquette supérieure de manière incrémentielle (à partir de 1). La requête d'écho transporte une valeur TLV d'informations multichemin qui transporte une plage d'adresses IP (dans la plage 127.0.0.0/8) ou une plage d'étiquettes d'entropie. Actuellement, les périphériques Cisco prennent en charge l'option de destination IP. Notre exemple sera donc détaillé avec la plage d'adresses IP.

Chaque LSR de transit à la réception du paquet de requête répond avec toutes les interfaces sortantes ECMP et associe une plage d'adresses IP (ou étiquette d'entropie) à partir de la requête pour chaque interface.

Trace de l'arborescence LSP - Exemple détaillé

Supposez la topologie suivante, par exemple ci-dessous.

Par souci de simplicité, cet exemple utilise la plage d'adresses 127.0.0.0-127.0.0.200. Voici les détails des étapes d'une trace d'arborescence LSP.

1) L'initiateur (R1) envoie la requête d'écho avec les détails ci-dessous :

• IP destination as 127.0.0.0
• TLV d’informations multichemin portant la plage d’adresses de 127.0.0.0 à 127.0.0.200.
• La durée de vie de l'étiquette supérieure est définie sur 1.

2) R2, à la réception de la même réponse, répond avec des informations multichemins pour chaque interface de sortie. Dans cet exemple, il répondra comme suit :

• Si la destination IP est comprise entre 127.0.0.0 et 127.0.0.100, le paquet est envoyé à R3.
• Si la destination IP est comprise entre 127.0.0.101 et 127.0.0.200, le paquet est envoyé à R6.

3) R1 se rend compte qu’il existe 2 chemins ECMP possibles et doit donc envoyer 2 requêtes d’écho avec une durée de vie de 2. A partir de différents tests, on a constaté que l'Initiateur finissait toujours par 1 chemin avant d'aller au suivant. (Mais cela peut être vrai pour une mise en oeuvre spécifique).

4) R1 envoie maintenant la requête d’écho avec les détails ci-dessous :

• IP destination as 127.0.0.0
• TLV d’informations multichemin portant la plage d’adresses de 127.0.0.0 à 127.0.0.100.
• La durée de vie de l'étiquette supérieure est définie sur 2.

5) R2 transfère le paquet à R3 (car l’adresse de destination est 127.0.0.0). R3, à la réception du même paquet, répondra avec les mêmes informations de trajets multiples, car il n'y a qu'une seule interface de sortie.

Il en va de même jusqu'à ce qu'il atteigne R5.

6) Une fois la trace PATH1 terminée (après réception de la réponse de sortie), l'initiateur interroge PATH2. Ceci est effectué en envoyant la requête d'écho avec les détails ci-dessous :

• IP destination as 127.0.0.101
• TLV d’informations multichemin portant la plage d’adresses de 127.0.0.101 à 127.0.0.200
• La durée de vie de l'étiquette supérieure est définie sur 2.

7) R2 transfère le paquet à R6 (car l’adresse de destination est 127.0.0.101). R6, à réception de ce message, répondra avec les informations de trajets multiples comme suit :

• Si la destination IP est comprise entre 127.0.0.101 et 127.0.0.150, le paquet est envoyé à R4.
• Si la destination IP est comprise entre 127.0.0.151 et 127.0.0.200, le paquet est envoyé à R7.

8) R1 se rend compte qu’il existe un chemin ECMP supplémentaire, ce qui fait que le nombre total de chemins possibles est égal à 3. R1 continue d’interroger PATH2 en envoyant la requête d’écho suivante avec les détails ci-dessous :

• IP destination as 127.0.0.101
• TLV d’informations multichemin portant la plage d’adresses de 127.0.0.101 à 127.0.0.150
• La durée de vie de l'étiquette supérieure est définie sur 3.

9) R2 transfère le paquet à R6 (car la destination est 127.0.0.101) et R6 le transfère à R4 (car la destination est 127.0.0.101). R4 n'a pas de chemin ECMP et répond donc avec les mêmes informations multichemins. Le paquet suivant atteint la sortie R5.

10) La trace PATH2 étant terminée, R1 poursuit la requête pour PATH3. Ceci est effectué en envoyant la requête d'écho avec les détails ci-dessous :

• IP destination as 127.0.0.151
• TLV d’informations multichemin portant la plage d’adresses de 127.0.0.151 à 127.0.0.200
• La durée de vie de l'étiquette supérieure est définie sur 3.

11) R2 transfère le paquet à R6, qui à son tour le transfère à R7. R7 répondra avec le même TLV d’informations de trajets multiples. Le paquet suivant atteint le routeur de sortie R5.

Une fois ces étapes terminées, R1 disposera des informations suivantes :

                            

En utilisant l’adresse de destination dans 127.0.0.0 et 127.0.0.100, le transfert de paquets sera influencé sur PATH1 tandis que l’utilisation de l’adresse d’autres plages influencera le transfert de paquets sur les chemins respectifs.

12) L’initiateur va maintenant envoyer 3 paquets de requête d’écho avec une durée de vie de 255 et sélectionner l’adresse de chaque plage afin que tous les chemins soient validés de bout en bout.

La commande à utiliser pour ECMP trace est traceroute mpls multipath ipv4 <prefix> <mask>. L'exemple suivant est un exemple de résultat.

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

Notez que la sortie ci-dessus montre qu'il y a 3 chemins et que tous fonctionnent correctement. En utilisant le bouton verbeux dans la commande ci-dessus, vous listerez tous les sauts comme ci-dessous :

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