Tracer la route dans le réseau MPLS
Contenu
Introduction
Ce document décrit le comportement de la commande traceroute ICMP (Internet Control Message Protocol) dans le réseau MPLS (Multiprotocol Label Switching) et une comparaison rapide avec la trace LSP.
Informations générales
Dans l'environnement IP, tout noeud qui reçoit un paquet et si le délai de vie (TTL) expire, il est prévu de générer “ message d'erreur TTL Dépassé ” ICMP (Type=11, Code=0) et de l'envoyer à l'adresse source du paquet. Ce concept est exploité afin de suivre le chemin IP de la source à la destination en envoyant un paquet UDP avec TTL commençant séquentiellement à 1. Il convient de noter que les exigences de base de cette fonctionnalité sont les suivantes :
- L’adresse source du paquet est accessible à partir des noeuds de transit
- ICMP n'est pas filtré le long du chemin
Dans l'environnement MPLS, un LSR de fournisseur de transit peut ne pas toujours avoir accès à l'adresse source et avoir besoin d'améliorations pour la gestion ICMP dans le domaine MPLS.
Traceroute ICMP dans le réseau MPLS
Le comportement par défaut de tout LSR lors de la réception d'un paquet avec TTL=1 sur l'étiquette supérieure suit le comportement IP traditionnel consistant à abandonner le paquet et à déclencher le message d'erreur ICMP. Afin de router le message ICMP vers la source, le LSR effectuera ceci :
- Mettre en mémoire tampon la pile d'étiquettes à partir du paquet entrant (paquet reçu avec TTL=1)
- Générez un message d'erreur ICMP avec la source comme adresse propre et la destination comme adresse source à partir du paquet reçu.
- Ajoutez toutes les étiquettes situées en bas de la pile d'étiquettes (qui a été mise en mémoire tampon plus tôt à l'étape 1) avec TTL=255, à l'exception de la pile supérieure.
- Obtenez l'étiquette supérieure de la pile d'étiquettes tamponnées et effectuez une recherche LFIB locale pour obtenir l'étiquette à échanger et le saut suivant associé.
- Ajoutez la nouvelle étiquette en haut de la pile avec TTL=255 et envoyez-la.
Avec cette approche, le message d'erreur ICMP traverse le LSR de transit vers le LER de sortie, puis revient au LER d'entrée vers la source réelle.
Suivi ICMP déclenché de PE à PE distant
Voici un exemple simple qui explique le comportement lorsque la trace ICMP est déclenchée de PE à PE distant dans le même domaine MPLS :
Dans cette topologie, lorsque la commande traceroute ICMP est déclenchée de R2 à 10.1.4.4, le premier paquet est envoyé avec une TTL de 1. R3 lors de la réception du paquet décrétera la durée de vie à 0 et déclenchera le mécanisme de génération ICMP.
R3 met en mémoire tampon la pile d'étiquettes et génère un message d'erreur ICMP et inclut la pile d'étiquettes entrantes à partir de la mémoire tampon dans la charge utile ICMP. Il remplit en outre l’en-tête IP avec l’adresse source de l’interface entrante du paquet étiqueté, l’adresse de destination comme source du paquet étiqueté. La durée de vie est définie sur 255. Il sort maintenant la pile d'étiquettes de la mémoire tampon et consulte la table LFIB pour l'action de transfert sur l'étiquette supérieure. Dans cette topologie, la pile d'étiquettes reçue est 17. Lors d'une recherche dans la table LFIB, l'étiquette 17 est échangée avec l'étiquette 16 et est transférée vers le routeur nexthop R6. R6, à son tour, affiche l’étiquette supérieure et la transmet à R4, qui réachemine le paquet vers R2.
Comme il peut être noté dans la sortie traceroute sur R2, l'étiquette entrante est indiquée par chaque saut sur le chemin.
Trace ICMP déclenchée de CE à CE distant
Voici un exemple simple qui explique le comportement lorsque la trace ICMP est déclenchée de CE à CE distant sur le domaine MPLS :
Dans cette topologie, lorsque la commande traceroute ICMP est déclenchée de R1 (CE) à 192.168.5.5 (CE distant), le premier paquet est envoyé avec la durée de vie de 1. Il s’agit d’un paquet IP normal et R2 suit donc le comportement traditionnel de génération d’ICMP et d’envoi direct à R1. Le deuxième paquet envoyé avec TTL=2 expirera à R3.
R3 met en mémoire tampon la pile d'étiquettes et génère un message d'erreur ICMP et inclut la pile d'étiquettes entrantes à partir de la mémoire tampon dans la charge utile ICMP. Il remplit en outre l’en-tête IP avec l’adresse source de l’interface entrante du paquet étiqueté, l’adresse de destination comme source du paquet étiqueté. La durée de vie est définie sur 255. Il sort maintenant la pile d'étiquettes de la mémoire tampon et consulte la table LFIB pour l'action de transfert sur l'étiquette supérieure. Dans la topologie ci-dessus, la pile d'étiquettes reçue est {17, 18}. Lors de la recherche d'une étiquette supérieure dans la table LFIB, 17 sera remplacé par l'étiquette 16 et sera transféré vers le routeur R6 nexthop. R6 à son tour affichera l'étiquette supérieure et la redirigera vers R4. R4 utilise l’étiquette VRF pour identifier le VRF et renvoyer le paquet vers R1.
Comme il peut être noté dans la sortie traceroute sur R1, la pile d'étiquettes entrantes est répertoriée par chaque saut le long du chemin.
MPLS LSP Traceroute dans le réseau MPLS
Contrairement à la commande traceroute basée sur ICMP, la commande traceroute LSP utilise la machine définie dans le document RFC4379. Il utilise l'encapsulation IP/UDP avec l'adresse de destination de la requête définie sur l'adresse de bouclage (plage 127.0.0.0/8). Il est prévu que la commande LSP Ping soit déclenchée dans le même domaine MPLS et que la réponse sera donc directement envoyée à l'initiateur.
Lorsque la commande LSP traceroute (“ traceroute mpls ipv4 <FEC> ”) est déclenchée à partir de n'importe quel LSR, les détails de la commande FEC à valider sont inclus dans un TLV en tant que “ pile FEC cible ” dans la requête d'écho MPLS. Ce message sera envoyé avec TTL sur la pile d'étiquettes en commençant séquentiellement par 1. Toute LSR de transit lors de la réception du paquet et si la durée de vie expire traitera le paquet IP, car l'adresse de destination est l'adresse de bouclage. et pointez vers le processeur pour le traitement MPLS OAM.
Le répondeur effectuera éventuellement la validation FEC en récupérant les étiquettes de la pile d'étiquettes de la demande d'écho MPLS reçue et les détails FEC de la pile de FEC cible TLV pour valider la même étiquette par rapport aux informations du plan de contrôle local. En cas de trace, le répondeur inclut les informations en aval telles que l'étiquette sortante et l'adresse de voisin en aval, etc., dans un TLV en tant que TLV DSMAP (Downstream Mapping). (La carte DSMAP sera désapprouvée par DDMAP car elle est plus flexible que la carte DSMAP).
Suivi LSP déclenché de PE à PE distant
Dans cette topologie, la trace LSP est déclenchée à partir de R2 pour valider le LSP sur le préfixe 10.1.4.4/32. La durée de vie sur l'étiquette est définie sur 1. R3 à sa réception envoie une requête ping au processeur pour le traitement OAM.
R3 répondra à R2 avec une réponse d'écho MPLS avec DSMAP TLV portant l'étiquette sortante 16 et des informations supplémentaires telles que les détails des voisins en aval. Contrairement aux messages ICMP, la réponse d’écho MPLS sera directement transmise de R3 répondeur à R2 initiateur.
Comme il peut être noté dans la sortie traceroute LSP sur R2, la pile d'étiquettes sortantes sera répertoriée par chaque saut sur le chemin. Ceci est différent de la commande traceroute basée sur ICMP où l'étiquette listée dans la sortie sera une pile d'étiquettes entrantes.
Trace LSP déclenchée de CE à CE distant
Ceci est applicable dans CSC comme dans les scénarios où MPLS est activé entre PE-CE. L'exécution de la trace LSP de CE à CE distant sur le domaine MPLS opérateur présente deux défis :
- La réponse d'écho LSP sera directement envoyée à l'initiateur. Ainsi, le répondeur DOIT être accessible à l'initiateur. Dans la topologie ci-dessus, R3 peut ne pas être accessible à R1 comme il l’est dans VRF.
- Pour chaque étiquette de la pile d'étiquettes, les détails FEC pertinents doivent être inclus dans la pile FEC cible pour validation. La FEC incluse par Initiator sera de 1, tandis que PE poussera 2 étiquettes. Dans la topologie ci-dessus, R1 envoie une requête d'écho MPLS avec FEC={192.168.5.5/32} et inclut l'étiquette 28 dans la pile. Puisque R2 échange l'étiquette 28 avec {17, 27}, R3 recevra la requête avec 2 étiquettes dans la pile tandis que 1 FEC dans TLV déroute la validation FEC.
Le document RFC6424 définit le concept de “ TLV FEC Stack Change ” pour traiter le problème 2. Ce TLV sera inclus en réponse avec le FEC pertinent en tant que PUSH/POP qui peut être inclus par l'initiateur dans la demande d'écho suivante.
draft-ietf-mpls-lsp-ping-relay-response définit le concept de transport de la pile d'adresses de noeud de relais dans TLV qui peut être utilisé par le répondeur pour relayer la réponse même s'il n'est pas accessible à l'initiateur.
Ces 2 problèmes ne sont pas actuellement pris en charge dans Cisco IOS® et le suivi LSP de CE à CE distant ne répertorie que le PE d'entrée et le CE distant. Ceci est inclus uniquement à des fins d'exhaustivité.
Commentaires