Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
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.
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 :
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.
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 :
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.
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.
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.
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).
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.
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 :
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é.