Commande Traceroute dans MPLS
Contenu
Introduction
Ce document explique la manière dont la commande « traceroute » fonctionne dans un environnement de commutation multiprotocole par étiquette (MPLS).
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
-
Connaissances MPLS de base
Référez-vous à FAQ MPLS pour les débutants pour plus d'informations.
Components Used
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
Conventions
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Commande Normale traceroute
Cette section décrit le fonctionnement d'une commande traceroute traditionnelle. Ce schéma montre une configuration de fournisseur de services où Router 1 (R1) et Router 4 (R4) sont des routeurs de périphérie du fournisseur (PE) et Router 2 (R2) et Router 3 (R3) sont des routeurs du fournisseur (P).
Cet exemple conduit une traceroute vers le bouclage R4 14 à partir de R1. R1 utilise un datagramme UDP (User Datagram Protocol) avec une valeur de port de destination arbitraire supérieure à 32000. Si vous sélectionnez une valeur aussi élevée pour le numéro de port, cela garantit qu'un tel port n'existe pas sur le destinataire prévu. Il place ce datagramme dans un paquet IP.
Remarque : Dans ce document, chaque fois qu'un paquet IP est mentionné, il s'agit d'un paquet IP qui contient le datagramme UDP.
Il s'agit d'une séquence d'événements pour une commande traceroute normale :
-
R1 envoie le paquet IP avec une adresse de destination de 14 et une durée de vie de 1 via son interface eth1.
-
R2 reçoit le paquet et note qu’il n’est pas le destinataire prévu et que la durée de vie du paquet est de 1. Il abandonne le paquet et envoie un message ICMP (Internet Control Message Protocol) expiré TTL à R1. L’adresse source de ce message ICMP est l’adresse IP de R2 eth0 (l’adresse de l’interface qui a reçu le paquet d’origine).
-
À la réception du message ICMP, R1 envoie un autre paquet IP destiné à 14 avec une TTL de 2 via son interface eth1.
-
R2 reçoit le paquet et note qu’il n’est pas le destinataire prévu et que le destinataire prévu peut être atteint via R3. Elle décrémente la durée de vie (de 2 à 1) et transfère le paquet à R3. R3 reçoit le paquet et s’assure qu’il n’est pas le destinataire prévu. La durée de vie est égale à 1. Il abandonne le paquet et envoie un message ICMP expiré TTL à R1 avec son adresse eth0 comme adresse source.
-
R1 reçoit le message ICMP et envoie un autre paquet IP à 14 via son interface eth1 avec une valeur TTL de 3. Sur le chemin, R2 et R3 décrément la durée de vie et la transmettent à R4. R4 obtient le paquet, s’assure qu’il est le destinataire prévu et tente de se connecter à la valeur du port dans le datagramme UDP. R4 trouve que ce port n'existe pas et envoie un message d'erreur port ICMP inaccessible à R1.
Comme précédemment, l’adresse source de ce message ICMP est eth0 de R4. Le programme traceroute a maintenant tous les messages d'erreur ICMP avec les adresses source correspondantes et a la route complète vers la destination.
Commande MPLS traceroute
Considérez ce même scénario détaillé dans la section Commande traceroute normale, à l'exception de tous les routeurs, R1 à R4, qui utilisent maintenant une étiquette de commutation au lieu de transmission IP. La configuration du banc d'essai est présentée dans ce schéma. Toutes les interfaces indiquées dans le banc d’essai se trouvent sur le réseau 10.13.0.0.
Aux fins du présent document, présumer que :
-
R1 utilise une étiquette de 47 pour atteindre R4 et transfère les paquets à R2.
-
R2 utilise une étiquette de 45 pour atteindre R4 et transfère les paquets à R3.
-
R3 affiche l’étiquette et transfère le paquet à R4.
-
R4 utilise une étiquette de 28 pour atteindre R1 et transfère les paquets à R3.
-
R3 utilise une étiquette de 26 pour atteindre R1 et transfère les paquets à R2.
-
R2 affiche l’étiquette et transfère le paquet à R1.
Ces étapes indiquent la séquence d'événements afin de mener une traceroute de R1 vers le bouclage R4 10.13.1.51.
-
R1 envoie un paquet à commutation d’étiquettes avec une étiquette de 47 et une TTL de 1 à R2. Le champ TTL du paquet IP est copié dans le champ TTL de l'en-tête d'étiquette.
-
R2 voit qu’il ne s’agit pas du destinataire prévu et que la durée de vie est de 1. Il abandonne le paquet et crée un message ICMP expiré TTL, comme pour un paquet IP normal. Dans ce cas, le paquet de messages ICMP est généré par les extensions ICMP pour MPLS.
-
R2 ajoute l'étiquette 47 (l'étiquette entrante qui a expiré) au message ICMP. Il n’envoie pas le paquet directement à R1. Au lieu de cela, il consulte sa base d'informations de transfert d'étiquettes (LFIB) et estime qu'il doit utiliser une étiquette de 45 pour les paquets reçus avec une étiquette de 47. Il place une étiquette de 45 sur le paquet et envoie le message ICMP expiré TTL à R3.
-
R3 affiche l’étiquette et l’envoie à R4. R4 voit que la destination est R1, donne une étiquette de 28 au message et l’envoie par R3 et R2 à R1.
-
Le message d’erreur ICMP se déplace jusqu’à l’autre extrémité avant d’être renvoyé à R1. Cet exemple fournit une illustration :
Les paquets analysés sur l’interface Ethernet de R4 confirment les étapes 1 à 5. Dans la sortie de l'analyseur, la trame 1 est le paquet entrant et la trame 2 est le paquet sortant de R4. Le résultat est formaté pour refléter cette discussion, et les points à noter sont en caractères gras.
Frame 1 (182 on wire, 182 captured) Ethernet II Destination: 00:04:4e:7a:74:00 (Cisco_7a:74:00) Source: 00:03:fd:1c:86:84 (Cisco_1c:86:84) Type: IP (0x0800) Internet Protocol Version: 4 Header length: 20 bytes Time to live: 254 Protocol: ICMP (0x01) Header checksum: 0x1b8e (correct) Source: 10.13.2.33 (10.13.2.33) Destination: 10.13.2.34 (10.13.2.34) Internet Control Message Protocol Type: 11 (Time-to-live exceeded) Code: 0 (TTL equals 0 during transit) Checksum: 0x0c88 (correct) Data (140 bytes) 04500 001c 9e19 0000 0111 044a 0a0d 0222E..........J..." 100a0d 0133 989d 829a 0008 cd37 0000 0000...3.......7.... 200000 0000 0000 0000 0000 0000 0000 0000................ 300000 0000 0000 0000 0000 0000 0000 0000................ 400000 0000 0000 0000 0000 0000 0000 0000................ 500000 0000 0000 0000 0000 0000 0000 0000................ 600000 0000 0000 0000 0000 0000 0000 0000................ 700000 0000 0000 0000 0000 0000 0000 0000................ 802000 edf2 0008 0101 0002 f101........... Frame 2 (186 on wire, 186 captured) Ethernet II Destination: 00:03:fd:1c:86:84 (Cisco_1c:86:84) Source: 00:04:4e:7a:74:00 (Cisco_7a:74:00) Type: MPLS label switched packet (0x8847) MultiProtocol Label Switching Header MPLS Label: Unknown (28) MPLS Experimental Bits: 6 MPLS Bottom Of Label Stack: 1 MPLS TTL: 253 Internet Protocol Version: 4 Header length: 20 bytes Time to live: 253 Protocol: ICMP (0x01) Header checksum: 0x1c8e (correct) Source: 10.13.2.33 (10.13.2.33) Destination: 10.13.2.34 (10.13.2.34) Internet Control Message Protocol Type: 11 (Time-to-live exceeded) Code: 0 (TTL equals 0 during transit) Checksum: 0x0c88 (correct) Data (140 bytes) 04500 001c 9e19 0000 0111 044a 0a0d 0222E..........J..." 100a0d 0133 989d 829a 0008 cd37 0000 0000...3.......7.... 200000 0000 0000 0000 0000 0000 0000 0000................ 300000 0000 0000 0000 0000 0000 0000 0000................ 400000 0000 0000 0000 0000 0000 0000 0000................ 500000 0000 0000 0000 0000 0000 0000 0000................ 600000 0000 0000 0000 0000 0000 0000 0000................ 700000 0000 0000 0000 0000 0000 0000 0000................ 802000 edf2 0008 0101 0002 f101...........
Dans la trame 1 du résultat, le premier paquet reçu par R4 est le message ICMP expiré par TTL de R2 (10.13.2.33, l’interface sur laquelle le paquet d’origine a été reçu) vers R1 (10.13.2.34). Dans la partie données du message ICMP, aux octets 0x89 et au premier quartet de 0x8A, l'étiquette MPLS (20 octets) a expiré et sa valeur est 0x02F, ou 47. Il s'agit de l'étiquette entrante du paquet avec une TTL de 1. R2 ajoute cette étiquette dans le message d'erreur ICMP.
Dans la trame 2 du résultat, le type est affiché en tant que paquet commuté d'étiquette MPLS, ce qui signifie qu'il s'agit d'un paquet MPLS. R4 place une étiquette de 28 à la trame 1 et la transfère à R1 via le chemin de commutation d’étiquette. L'en-tête MPLS de la trame est en gras. En outre, si vous faites référence à la partie TTL du paquet, dans la trame 1, sa valeur est 254 et dans la trame 2, elle est 253. R4 l'a décrémenté de 1.
-
R1 reçoit le message ICMP et envoie un autre paquet avec une étiquette de 47 et une TTL de 2 à R2. R2 échange les étiquettes, décréte la durée de vie (de 2 à 1) et transmet à R3. Comme à l'étape 2, R3 envoie un message ICMP expiré par TTL, ajouté avec l'étiquette entrante qui a expiré à R4, et R4 le renvoie ensuite à R1.
La sortie du renifleur à R4, représentée ici, confirme l'étape 6 :
Frame 3 (182 on wire, 182 captured) Ethernet II Destination: 00:04:4e:7a:74:00 (Cisco_7a:74:00) Source: 00:03:fd:1c:86:84 (Cisco_1c:86:84) Type: IP (0x0800) Internet Protocol Version: 4 Header length: 20 bytes Time to live: 255 Protocol: ICMP (0x01) Header checksum: 0x146f (correct) Source: 10.13.3.134 (10.13.3.134) Destination: 10.13.2.34 (10.13.2.34) Internet Control Message Protocol Type: 11 (Time-to-live exceeded) Code: 0 (TTL equals 0 during transit) Checksum: 0x0c88 (correct) Data (140 bytes) 04500 001c 9e1b 0000 0211 0348 0a0d 0222E..........H..." 100a0d 0133 9292 829b 0008 d341 0000 0000...3.......A.... 200000 0000 0000 0000 0000 0000 0000 0000................ 300000 0000 0000 0000 0000 0000 0000 0000................ 400000 0000 0000 0000 0000 0000 0000 0000................ 500000 0000 0000 0000 0000 0000 0000 0000................ 600000 0000 0000 0000 0000 0000 0000 0000................ 700000 0000 0000 0000 0000 0000 0000 0000................ 802000 0df3 0008 0101 0002 d101........... Frame 4 (186 on wire, 186 captured) Ethernet II Destination: 00:03:fd:1c:86:84 (Cisco_1c:86:84) Source: 00:04:4e:7a:74:00 (Cisco_7a:74:00) Type: MPLS label switched packet (0x8847) MultiProtocol Label Switching Header MPLS Label: Unknown (28) MPLS Experimental Bits: 6 MPLS Bottom Of Label Stack: 1 MPLS TTL: 254 Internet Protocol Version: 4 Header length: 20 bytes Time to live: 254 Protocol: ICMP (0x01) Header checksum: 0x156f (correct) Source: 10.13.3.134 (10.13.3.134) Destination: 10.13.2.34 (10.13.2.34) Internet Control Message Protocol Type: 11 (Time-to-live exceeded) Code: 0 (TTL equals 0 during transit) Checksum: 0x0c88 (correct) Data (140 bytes) 04500 001c 9e1b 0000 0211 0348 0a0d 0222E..........H..." 100a0d 0133 9292 829b 0008 d341 0000 0000...3.......A.... 200000 0000 0000 0000 0000 0000 0000 0000................ 300000 0000 0000 0000 0000 0000 0000 0000................ 400000 0000 0000 0000 0000 0000 0000 0000................ 500000 0000 0000 0000 0000 0000 0000 0000................ 600000 0000 0000 0000 0000 0000 0000 0000................ 700000 0000 0000 0000 0000 0000 0000 0000................ 802000 0df3 0008 0101 0002 d101...........
À partir de la sortie de la trame 3, vous pouvez déterminer que la trame 3 est le paquet ICMP de R3 à R1. L’adresse source (10.13.3.134) est l’adresse sur laquelle le paquet d’origine est reçu. Le message d'erreur ICMP contient les informations d'étiquette expirées à la fin de la partie données. Sa valeur est 0x02d, soit 45. La trame 4 est le paquet MPLS envoyé de R4 à R1.
-
Dès réception du message ICMP, R1 envoie un autre paquet avec une étiquette de 47 et une TTL de 3. En chemin, R2 et R3 décrément la durée de vie et transmettent le paquet à R4. R4 note qu’il s’agit du destinataire prévu et trouve le port de datagramme UDP inaccessible. Il envoie un message de port ICMP inaccessible à R1 via R3 et R2.
Dans cette sortie de renifleur, les points importants à noter sont en gras :
Frame 5 (60 on wire, 60 captured) Ethernet II Destination: 00:04:4e:7a:74:00 (Cisco_7a:74:00) Source: 00:03:fd:1c:86:84 (Cisco_1c:86:84) Type: IP (0x0800) Trailer: 00000000000000000000000000000000... Internet Protocol Version: 4 Header length: 20 bytes Time to live: 1 Protocol: UDP (0x11) Header checksum: 0x0446 (correct) Source: 10.13.2.34 (10.13.2.34) Destination: 10.13.1.51 (10.13.1.51) User Datagram Protocol Source port: 37647 (37647) Destination port: 33436 (33436) Length: 8 Checksum: 0xd2c3 (correct) Frame 6 (74 on wire, 74 captured) Ethernet II Destination: 00:03:fd:1c:86:84 (Cisco_1c:86:84) Source: 00:04:4e:7a:74:00 (Cisco_7a:74:00) Type: MPLS label switched packet (0x8847) MultiProtocol Label Switching Header MPLS Label: Unknown (28) MPLS Experimental Bits: 6 MPLS Bottom Of Label Stack: 1 MPLS TTL: 255 Internet Protocol Version: 4 Header length: 20 bytes Time to live: 255 Protocol: ICMP (0x01) Header checksum: 0x5694 (correct) Source: 10.13.5.10 (10.13.5.10) Destination: 10.13.2.34 (10.13.2.34) Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 3 (Port unreachable) Checksum: 0x1485 (correct) Data (28 bytes) 04500 001c 9e1d 0000 0111 0446 0a0d 0222E..........F..." 100a0d 0133 930f 829c 0008 d2c3...3........
La trame 5 montre que le datagramme UDP est envoyé par R1 à R4. La valeur du port de destination dans le datagramme UDP est 33436 (supérieure à 32000), comme indiqué dans la section Commande traceroute normale.
Dans la trame 6, R4 envoie un type ICMP destination inaccessible et un code port inaccessible à R1. Tous les messages ICMP précédents de R2 et R3 avaient le champ de type défini comme durée de vie dépassée. La sortie de la commande traceroute étendue est affichée ici :
R1#traceroute Protocol [ip]: Target IP address: 10.13.1.51 Source address: 10.13.2.34 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: 1 Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 10.13.1.51 1 10.13.2.33 [MPLS: Label 47 Exp 0] 0 msec 2 10.13.3.134 [MPLS: Label 45 Exp 0] 0 msec 3 10.13.5.10 4 msec R1#
Par défaut, la commande traceroute utilise trois sondes pour chaque valeur TTL. Il envoie trois paquets avec une TTL de 1, trois paquets avec une TTL de 2, etc. Cette commande traceroute est exécutée avec une seule sonde, il est donc facile de suivre et de déboguer. Comme le montre le résultat, la commande traceroute affiche également la valeur d'étiquette expirée.
no mpls ip propagate-ttl, commande
Lorsque vous configurez MPLS, une étiquette est imposée par le routeur de commutation d'étiquettes (LSR) lorsqu'un paquet IP est transféré dans le domaine MPLS. Cette étiquette doit avoir une valeur dans le champ TTL. Par défaut, LSR lit le champ TTL dans l'en-tête IP du paquet entrant, le décrémente par 1 et copie ce qui reste dans le champ TTL de l'en-tête MPLS. Les LSR principaux ne regardent que l'étiquette supérieure. Si la valeur TTL n’atteint pas 0, le paquet est transféré. Le LSR de périphérie de sortie qui affiche l'étiquette copie ce qui reste dans le champ TTL de l'étiquette dans le champ TTL de l'en-tête IP, puis transfère le paquet IP en dehors du domaine MPLS.
Ce comportement peut être modifié à l'aide de la commande de configuration no mpls ip propagate-ttl. Le LSR de périphérie d'entrée utilise la valeur 255 comme valeur TTL dans l'étiquette lors de son imposition. Le LSR du bord de sortie ne copie pas la valeur TTL de l'étiquette dans l'en-tête IP lors de l'ajout de l'étiquette. Le résultat net est que l’en-tête IP TTL ne reflète pas les sauts pris sur le coeur MPLS ; donc, lorsque les clients exécutent une commande traceroute d'un côté de leur réseau à un autre, les routeurs du réseau principal MPLS n'apparaissent pas dans les informations traceroute. Il est important de désactiver la propagation TTL dans les LSR d'entrée et de sortie. Sinon, l'en-tête IP peut avoir une valeur plus élevée lorsqu'il quitte le domaine MPLS qu'il ne l'avait lors de sa saisie.
Voici un exemple :
C1 effectue une traceroute vers C2. Avec l'opération de propagation TTL IP par défaut, la traceroute dans C1 ressemble à ceci :
C1#traceroute C2.cust.com Tracing the route to C2.cust.com 1 A.provider.net 44 msec 36 msec 32 msec 2 B provider.net 164 msec 132 msec 128 msec 3 C.provider.net 148 msec 156 msec 152 msec 4 C2.cust.com 180 msec * 181 msec
Cette sortie illustre le comportement typique de traceroute dans un réseau MPLS. Comme l’en-tête d’étiquette d’un paquet étiqueté transporte la valeur TTL du paquet IP d’origine, les routes du chemin abandonnent les paquets pour lesquels la TTL est dépassée. Par conséquent, traceroute affiche tous les routeurs du chemin. Le comportement est le suivant :
-
Le premier paquet est un paquet IP dont la durée de vie est égale à 1. Le routeur A décrémente la durée de vie et abandonne le paquet car il atteint 0. Un message ICMP TTL dépassé est envoyé à la source.
-
Le deuxième paquet envoyé est un paquet IP avec TTL égal à 2. Le routeur A décréte la durée de vie, étiquette le paquet et transmet le paquet au routeur B.
-
Le routeur B décrémente la valeur TTL dans l’en-tête MPLS, abandonne le paquet et envoie un message ICMP TTL-overdose à la source. Comme il s’agissait d’un paquet MPLS abandonné, l’adresse de retour du message ICMP doit être dérivée de l’adresse source dans l’en-tête IP à l’intérieur du paquet MPLS. Mais cette adresse IP peut en fait ne pas être connue du routeur B, de sorte que le routeur B transmet les messages ICMP le long du même chemin commuté d'étiquette (LSP) que le paquet abandonné voyageait (dans la direction vers le routeur C). À la fin du LSP, l’étiquette est supprimée et les messages ICMP sont transférés en fonction de l’adresse de destination dans l’en-tête IP (vers le routeur C1).
-
Le troisième paquet (TTL est 3) subit le même traitement que les paquets précédents, à ceci près que le routeur C est maintenant celui qui abandonne le paquet, en fonction de TTL dans l'en-tête IP. Le routeur B, en raison de l'avant-dernier saut, a précédemment supprimé l'étiquette et la durée de vie a été copiée dans l'en-tête IP.
-
Le quatrième paquet (TTL = 4) atteint la destination finale où la TTL de l’en-tête IP est examinée.
Si la propagation TTL IP est désactivée avec la commande no mpls ip propagate-ttl en mode de configuration globale, la valeur TTL n'est pas copiée dans l'en-tête IP et la traceroute de C1 à C2 ressemble à ceci :
C1#traceroute C2.cust.com Tracing the route to C2.cust.com 1 A.provider.net 44 msec 36 msec 32 msec 2 C2.cust.com 180 msec * 181 msec
Lorsque la commande traceroute est utilisée dans cette situation, les réponses ICMP ne sont reçues que des routeurs qui voient la durée de vie réelle stockée dans l'en-tête IP. Dans cette situation, le routeur C1 exécute une commande traceroute (comme illustré), mais les routeurs principaux ne copient pas la durée de vie vers et depuis l’étiquette. Il en résulte ce comportement :
-
Le premier paquet est un paquet IP dont la durée de vie est égale à 1. Le routeur A décrémente la durée de vie, abandonne le paquet et envoie un message ICMP TTL-overdose à la source.
-
Le deuxième paquet est un paquet IP avec une durée de vie égale à 2. Le routeur A décréte la durée de vie, étiquette le paquet et définit la durée de vie dans l’en-tête MPLS sur 255.
-
Le routeur B décrémente la durée de vie dans l'en-tête MPLS sur 254, supprime l'étiquette MPLS et copie la valeur de durée de vie dans l'en-tête MPLS dans le champ TTL de l'en-tête IP.
-
Le routeur C décrémente la durée de vie IP et envoie le paquet au tronçon suivant du routeur C2. Le paquet a atteint sa destination finale.
Commentaires