Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Sur cette page
 

Dépannage MPLS

Vérifier les interfaces MPLS

But

Si le protocole MPLS n’est pas configuré correctement sur les routeurs de votre réseau, les interfaces ne sont pas en mesure d’effectuer la commutation MPLS.

REMARQUE :

Pour qu’une route étiquetée soit résolue via une interface, family mpls elle doit être configurée au niveau de la [edit interfaces] hiérarchie pour que la route soit résolue avec succès. Lorsque l’interface n’est pas configurée avec family mpls, les routes étiquetées ne sont pas résolues.

Action

Pour vérifier les interfaces MPLS, entrez la commande suivante Junos OS mode opérationnel de l’interface de ligne de commande (CLI) :

Sortie de l’échantillon 1

nom_commande

L’exemple de sortie suivant concerne tous les routeurs du réseau affiché dans Topologie de réseau MPLS.

Sortie de l’échantillon 2

nom_commande

Sortie de l’échantillon 3

nom_commande

Sens

L’exemple de sortie 1 montre que toutes les interfaces MPLS sur tous les routeurs du réseau sont activées (Up) et peuvent effectuer une commutation MPLS. Si vous ne parvenez pas à configurer l’interface correcte au niveau de la hiérarchie [edit protocols mpls] ou si vous n’incluez pas l’instruction family mpls au niveau de la hiérarchie [edit interfaces type-fpc/pic/port unit number ], l’interface ne peut pas effectuer de commutation MPLS et n’apparaît pas dans la sortie de la show mpls interface commande.

Les groupes d’administration ne sont configurés sur aucune des interfaces présentées dans l’exemple de réseau dans la topologie de réseau MPLS. Toutefois, si c’était le cas, la sortie indiquerait quels bits de classe d’affinité sont activés sur le routeur.

L’exemple de sortie 2 montre que l’interface so-0/0/2.0 est manquante et qu’elle est donc peut-être mal configurée. Par exemple, il se peut que l’interface ne soit pas incluse au niveau de la hiérarchie [edit protocols mpls] ou que l’instruction family mpls ne soit pas incluse au niveau de la hiérarchie [edit interfaces type-fpc/pic/port unit number]. Si l’interface est configurée correctement, il se peut que RSVP n’ait pas encore été signalé sur cette interface. Pour plus d’informations sur la façon de déterminer quelle interface est mal configurée, consultez Vérifier les familles de protocoles.

L’exemple de sortie 3 montre que le protocole MPLS n’est pas configuré au niveau de la hiérarchie [edit protocols mpls].

Vérifier les familles de protocoles

But

Si MPLS n’est pas activé sur une interface logique, elle ne peut pas effectuer de commutation MPLS. Cette étape vous permet de déterminer rapidement quelles interfaces sont configurées avec MPLS et d’autres familles de protocoles.

Action

Pour vérifier les familles de protocoles configurées sur les routeurs de votre réseau, entrez la commande suivante en mode opérationnel de l’interface de ligne de commande Junos OS :

Sortie de l’échantillon 1

nom_commande

Sortie de l’échantillon 2

nom_commande

Sens

L’exemple de sortie 1 montre l’interface, l’état administratif de la liaison (Admin), l’état de la couche de liaison de données de la liaison (Link), les familles de protocoles configurées sur l’interface (Proto) et les adresses locale et distante sur l’interface.

Toutes les interfaces de toutes les routes du réseau affichées dans la topologie de réseau MPLS sont activées administrativement et fonctionnent au niveau de la couche de liaison de données avec MPLS et IS-IS, et disposent d’une inet adresse. Tous sont configurés avec une famille de protocoles IPv4 (inet), et les familles de protocoles IS-IS (iso) et MPLS (mpls) sont configurées au niveau de la hiérarchie [edit interfaces type-fpc/pic/port unit number].

L’exemple de sortie 2 montre que l’instruction mpls de l’interface so-0/0/2.0 activée R6 n’est pas incluse au niveau de la hiérarchie [edit interfaces type-fpc/pic/port unit number].

Vérification de la configuration MPLS

But

Une fois que vous avez vérifié les routeurs de transit et d’entrée, utilisé la traceroute commande pour vérifier le tronçon suivant BGP et utilisé la ping commande pour vérifier le chemin actif, vous pouvez vérifier les problèmes liés à la configuration MPLS aux [edit protocols mpls] niveaux et [edit interfaces] hiérarchie.

REMARQUE :

Pour qu’une route étiquetée soit résolue via une interface, family mpls elle doit être configurée au niveau de la [edit interfaces] hiérarchie pour que la route soit résolue avec succès. Lorsque l’interface n’est pas configurée avec family mpls, les routes étiquetées ne sont pas résolues.

Action

Pour vérifier la configuration MPLS, entrez les commandes suivantes à partir des routeurs entrants, de transit et de sortie :

Sortie de l’échantillon 1

nom_commande

Sortie de l’échantillon 2

nom_commande

Sens

L’exemple de sortie 1 des routeurs entrants, de transit et de sortie montre que la configuration des interfaces sur le routeur de sortie R6 est incorrecte. L’interface so-0/0/3.0 est considérée comme inactive au niveau de la hiérarchie [edit protocols mpls], alors qu’elle devrait l’être, car il s’agit de l’interface par laquelle le LSP transite.

L’exemple de sortie 2 montre que les interfaces sont correctement configurées pour MPLS sur le routeur de sortie R6. Les interfaces sont également correctement configurées sur les routeurs d’entrée et de transit (non illustrés).

Vérification de la couche MPLS

But

Une fois que vous avez configuré le chemin de commutation d’étiquettes (LSP), émis la show mpls lsp commande et déterminé qu’il existe une erreur, vous constaterez peut-être que l’erreur ne se trouve pas dans les couches physiques, de liaison de données, de protocole Internet (IP), de protocole de passerelle intérieure (IGP) ou de protocole de réservation de ressources (RSVP). Poursuivez l’examen du problème au niveau de la couche MPLS du réseau.

Figure 1 illustre la couche MPLS du modèle MPLS en couches.

Figure 1 : Vérification de la couche MPLSVérification de la couche MPLS

Avec la couche MPLS, vous vérifiez si le LSP est opérationnel et fonctionne correctement. Si le réseau ne fonctionne pas au niveau de cette couche, le LSP ne fonctionne pas comme configuré.

Figure 2 illustre le réseau MPLS utilisé dans cette rubrique.

Figure 2 : Réseau MPLS interrompu au niveau de la couche MPLSRéseau MPLS interrompu au niveau de la couche MPLS

Le réseau illustré ci-dessous Figure 2 est une configuration entièrement maillée dans laquelle chaque interface directement connectée peut recevoir et envoyer des paquets à toutes les autres interfaces similaires. Le LSP de ce réseau est configuré pour fonctionner depuis le routeur R1entrant , via le routeur R3de transit , jusqu’au routeur de sortie R6. En outre, un LSP inverse est configuré pour s’exécuter de A R3R1à R6 , créant ainsi un trafic bidirectionnel.

Toutefois, dans cet exemple, le LSP inverse est vers le bas sans chemin de R6 vers .R1

La croix illustrée en Figure 2 indique l’endroit où le LSP est brisé. Parmi les raisons possibles pour lesquelles le LSP est cassé, citons un protocole MPLS mal configuré ou des interfaces mal configurées pour MPLS.

Dans le réseau illustré à Figure 2, une erreur de configuration sur le routeur de sortie R6 empêche le LSP de traverser le réseau comme prévu.

Pour vérifier la couche MPLS, procédez comme suit :

Vérifier le LSP

But

En règle générale, vous utilisez la show mpls lsp extensive commande pour vérifier le LSP. Toutefois, pour une vérification rapide de l’état du LSP, utilisez la show mpls lsp commande. Si le LSP est en panne, utilisez l’option extensive (show mpls lsp extensive) comme suivi. Si votre réseau compte de nombreux LSP, vous pouvez envisager de spécifier le nom du fournisseur de services linguistiques à l’aide de l’option name (show mpls lsp name name ou show mpls lsp name name extensive).

Action

Pour vérifier que le LSP est actif, entrez tout ou partie des commandes suivantes à partir du routeur entrant :

Sortie de l’échantillon 1
nom_commande
Sortie de l’échantillon 2
nom_commande
Sortie de l’échantillon 3
nom_commande
Sortie de l’échantillon 4
nom_commande

Sens

L’exemple de sortie 1 présente une brève description de l’état du LSP pour les routeurs d’entrée, de transit et de sortie. La sortie du routeur entrant R1 et du routeur de sortie R6 montre que les deux LSP sont inactifs, R1-to-R6 et R6-toR1. Si les LSP configurés sont activés R1 et R6, on peut s’attendre à ce que des sessions LSP de sortie soient créées sur les deux R1 et R6. De plus, le routeur R3 de transit n’a aucune session de transit.

L’exemple de sortie 2 affiche toutes les informations sur les LSP, y compris tout l’historique des états passés et la raison de l’échec d’un LSP. La sortie de R1 et R6 indique qu’il n’y a pas d’itinéraire vers la destination, car l’algorithme CSPF (Constrained Shortest Path First) a échoué.

Les exemples de sorties 3 et 4 montrent des exemples de sortie pour la show mpls lsp name commande avec l’option extensive . Dans ce cas, la sortie est très similaire à la show mpls lsp commande, car un seul LSP est configuré dans l’exemple de réseau dans MPLS Network Broken au niveau de la couche MPLS. Cependant, dans un grand réseau avec de nombreux LSP configurés, les résultats seraient très différents entre les deux commandes.

Vérifier la route LSP sur le routeur de transit

But

Si le LSP est actif, il doit apparaître dans la mpls.0 table de routage. MPLS gère une table de routage de chemin MPLS (mpls.0), qui contient la liste du prochain routeur à commutation d’étiquettes dans chaque LSP. Cette table de routage est utilisée sur les routeurs de transit pour acheminer les paquets vers le routeur suivant le long d’un LSP. Si aucune route n’est présente dans la sortie du routeur de transit, vérifiez la configuration du protocole MPLS sur les routeurs d’entrée et de sortie.

Action

Pour vérifier la route LSP sur le routeur de transit, entrez la commande suivante à partir du routeur de transit :

Sortie de l’échantillon 1
nom_commande
Sortie de l’échantillon 2
nom_commande

Sens

L’exemple de sortie 1 du routeur R3 de transit montre trois entrées de route sous la forme d’entrées d’étiquettes MPLS. Ces étiquettes MPLS sont des étiquettes MPLS réservées définies dans le document RFC 3032 et sont toujours présentes dans la mpls.0 table de routage, quel que soit l’état du LSP. Les étiquettes entrantes attribuées par RSVP au voisin en amont sont manquantes dans la sortie, ce qui indique que le LSP est inactif. Pour plus d’informations sur les entrées d’étiquettes MPLS, consultez Liste de contrôle pour la vérification de l’utilisation des LSP.

En revanche, l’exemple de sortie 2 affiche les étiquettes et les routes MPLS d’un LSP correctement configuré. Les trois étiquettes MPLS réservées sont présentes, et les quatre autres entrées représentent les étiquettes entrantes attribuées par RSVP au voisin en amont. Ces quatre entrées représentent deux itinéraires. Il y a deux entrées par route, car les valeurs de pile dans l’en-tête MPLS peuvent être différentes. Pour chaque route, la deuxième entrée 100864 (S=0) indique 100880 (S=0) que la profondeur de la pile n’est pas égale à 1 et que des valeurs d’étiquette supplémentaires sont incluses dans le paquet. En revanche, la première entrée, 100864 et 100880 a une valeur déduite S = 1 qui indique une profondeur de pile de 1 et fait de chaque étiquette la dernière étiquette de ce paquet particulier. Les doubles entrées indiquent qu’il s’agit de l’avant-dernier routeur. Pour plus d’informations sur l’empilage d’étiquettes MPLS, reportez-vous à la RFC 3032, Codage d’empilement d’étiquettes MPLS.

Vérifier la route LSP sur le routeur entrant

But

Vérifiez si la route LSP est incluse dans les entrées actives de la inet.3 table de routage pour l’adresse spécifiée.

Action

Pour vérifier la route LSP, entrez la commande suivante à partir du routeur entrant :

Sortie de l’échantillon 1
nom_commande
Sortie de l’échantillon 2
nom_commande

Sens

L’exemple de sortie 1 affiche uniquement les entrées de la inet.0 table de routage. La inet.3 table de routage est absente de la sortie car le LSP ne fonctionne pas. La inet.0 table de routage est utilisée par les protocoles IGP (Interior Gateway Protocol) et BGP (Border Gateway Protocol) pour stocker les informations de routage. Dans ce cas, l’IGP est l’acronyme IS-IS (Intermediate System-to-Intermediate System). Pour plus d’informations sur la inet.0 table de routage, reportez-vous au Guide de configuration des applications MPLS Junos.

Si le LSP fonctionnait, nous nous attendrions à voir des entrées qui incluent le LSP dans la inet.3 table de routage. La inet.3 table de routage est utilisée sur les routeurs entrants pour acheminer les paquets BGP vers le routeur de sortie de destination. BGP utilise la inet.3 table de routage du routeur entrant pour résoudre les adresses de saut suivant. BGP est configuré dans l’exemple de réseau illustré dans Réseau MPLS interrompu au niveau de la couche MPLS.

L’exemple de sortie 2 montre la sortie que vous devriez recevoir lorsque le LSP est actif. La sortie affiche à la fois les tables de routage et inet.3 , inet.0 indiquant que les R1-to-R6 LSP et R6-to-R1 sont disponibles.

Vérifier les étiquettes MPLS à l’aide de la commande traceroute

But

Affichez le routage que les paquets acheminent vers une destination BGP où le prochain saut BGP de cette route est l’adresse de sortie LSP. Par défaut, BGP utilise les tables de routage et inet.0 pour inet.3 résoudre l’adresse du saut suivant. Lorsque l’adresse de saut suivant de la route BGP n’est pas l’ID de routeur du routeur de sortie, le trafic est mappé aux routes IGP et non au LSP. Utilisez la traceroute commande comme outil de débogage pour déterminer si le LSP est utilisé pour transférer le trafic.

Action

Pour vérifier les étiquettes MPLS, entrez la commande suivante à partir du routeur entrant :

Sortie de l’échantillon 1
nom_commande
Sortie de l’échantillon 2
nom_commande

Sens

L’exemple de sortie 1 montre que le trafic BGP n’utilise pas le LSP et que, par conséquent, les étiquettes MPLS n’apparaissent pas dans la sortie. Au lieu d’utiliser le LSP, le trafic BGP utilise l’IGP (IS-IS, dans l’exemple de réseau dans MPLS Réseau interrompu au niveau de la couche MPLS) pour atteindre l’adresse de sortie du LSP BGP next-hop. Le comportement par défaut de Junos OS utilise des LSP pour le trafic BGP lorsque le saut suivant BGP est égal à l’adresse de sortie LSP.

L’exemple de sortie 2 est un exemple de sortie pour un LSP correctement configuré. La sortie affiche des étiquettes MPLS, ce qui indique que le trafic BGP utilise le LSP pour atteindre le tronçon BGP suivant.

Vérifier les étiquettes MPLS à l’aide de la commande ping

But

Lorsque vous envoyez une requête ping à un LSP spécifique, vous vérifiez que les requêtes d’écho sont envoyées sur le LSP sous forme de paquets MPLS.

Action

Pour vérifier les étiquettes MPLS, entrez la commande suivante à partir du routeur entrant pour envoyer une requête ping au routeur de sortie :

Par exemple :

Sortie de l’échantillon 1
nom_commande
Sortie de l’échantillon 2
nom_commande

Sens

L’exemple de sortie 1 montre que le LSP n’a pas de chemin actif pour transférer les demandes d’écho, ce qui indique que le LSP est inactif.

L’exemple de sortie 2 est un exemple de sortie que vous devez recevoir lorsque le LSP est opérationnel et transfère des paquets.

Prendre les mesures qui s’imposent

Problème

Description

En fonction de l’erreur que vous avez rencontrée lors de votre investigation, vous devez prendre les mesures appropriées pour corriger le problème. Dans cet exemple, une interface est mal configurée au niveau de la hiérarchie [edit protocols mpls] sur le routeur de sortie R6.

Solution

Pour corriger l’erreur dans cet exemple, procédez comme suit :

  1. Activez l’interface dans la configuration du protocole MPLS sur le routeur de sortie R6:

  2. Vérifiez et validez la configuration :

Exemple de sortie
Sens

L’exemple de sortie montre que l’interface so-0/0/3.0 mal configurée sur le routeur de sortie est maintenant activée au niveau de R6 la hiérarchie [edit protocols mpls]. Le LSP peut maintenant apparaître.

Vérifiez à nouveau le LSP

But

Après avoir pris les mesures appropriées pour corriger l’erreur, le LSP doit être vérifié à nouveau pour confirmer que le problème dans la couche BGP a été résolu.

Action

Pour vérifier à nouveau le LSP, entrez la commande suivante à partir des routeurs entrants, de transit et de sortie :

Exemple de sortie
nom_commande

Sens

L’exemple de sortie 1 du routeur entrant R1 montre que LSP R1-to-R6 a une route active vers R6 et que l’état est actif.

L’exemple de sortie 2 du routeur R3 de transit montre qu’il existe deux sessions LSP de transit, l’une de R1 vers et R6 l’autre de R6 vers R1. Les deux LSP sont en hausse.

L’exemple de sortie 3 du routeur de sortie R6 montre que le LSP est actif et que l’itinéraire actif est l’itinéraire principal. Le LSP traverse maintenant le réseau le long du chemin attendu, de R1 à , R3R6et le LSP inverse, de R6 à travers R3 vers R1.

Vérifier la sauvegarde individuelle

But

Vous pouvez vérifier qu’une sauvegarde un-à-un est établie en examinant le routeur entrant et les autres routeurs du réseau.

Action

Pour vérifier la sauvegarde individuelle, entrez les commandes suivantes en mode opérationnel de l’interface de ligne de commande Junos OS :

Exemple de sortie

nom_commande

L’exemple de sortie suivant provient du routeur entrant R1 :

Sens

L’exemple de sortie de R1 montre que l’objet FastReroute desired a été inclus dans les messages de chemin pour le LSP, ce qui permet R1 de sélectionner le chemin actif pour le LSP et d’établir un chemin de détour pour éviter R2.

À la ligne 8, Fast-reroute Detour Up indique que la déviation est opérationnelle. Les lignes 6 et 7 indiquent que les routeurs de R2 transit et R4 ont établi leurs chemins de détour.

R2, 10.0.12.14, includes (flag=9), indiquant que la protection de noeud est disponible pour le noeud et le lien en aval. R4, 10.0.24.2, inclut (flag=1), indiquant que la protection de liaison est disponible pour la liaison en aval suivante. Dans ce cas, R4 ne peut protéger que la liaison en aval car le nœud est le routeur de sortie R5, qui ne peut pas être protégé. Pour plus d’informations sur les indicateurs, reportez-vous au Guide de l’utilisateur Junos.

La sortie de la show mpls lsp extensive commande n’affiche pas le chemin réel du détour. Pour voir les liens réels utilisés par les chemins de détour, vous devez utiliser la show rsvp session ingress detail commande.

Exemple de sortie

L’exemple de sortie suivant provient du routeur entrant R1 dans le réseau indiqué dans Détours de sauvegarde un à un.

Sens

L’exemple de sortie de R1 montre la session RSVP du LSP principal. Le chemin de détour est établi, Detour is Up. Le chemin physique de la déviation est affiché dans Detour Explct route. Le chemin de détour utilise R7 et R9 comme routeurs de transit pour atteindre R5, le routeur de sortie.

Exemple de sortie

L’exemple de sortie suivant provient du premier routeur de transit R2 du réseau illustré dans Détours de sauvegarde un à un :

Sens

L’exemple de sortie de R2 montre que le détour est établi (Detour is Up) et évite R4, et que la liaison se connectant R4 et R5 (10.0.45.2). Le chemin de détour passe par R7 (10.0.27.2) et R9 (10.0.79.2) vers R5 (10.0.59.1), ce qui est différent de l’itinéraire explicite pour le détour de R1. R1 a le détour passant par le 10.0.17.14 lien sur R7, tandis que R1 utilise le 10.0.27.2 lien. Les deux détours se rejoignent à R9 travers le 10.0.79.2 lien vers R5 (10.0.59.1).

Exemple de sortie

L’exemple de sortie suivant provient du deuxième routeur de transit R4 dans le réseau illustré dans Détours de sauvegarde un à un :

Sens

L’exemple de sortie de R4 montre que le détour est établi (Detour is Up) et évite que le lien ne se connecte R4 et R5 (10.0.45.2). Le chemin de détour passe par R9 (10.0.49.2) jusqu’à R5 (10.0.59.1). Certaines informations sont similaires à celles trouvées dans la sortie pour R1 et R2. Cependant, l’itinéraire explicite pour la déviation est différent, passant par la liaison reliant R4 et R9 (so-0/0/3 ou 10.0.49.2.

Exemple de sortie

L’exemple de sortie suivant provient de , qui est utilisé dans le chemin de R7détour dans le réseau affiché dans Détours de sauvegarde un à un :

Sens

L’exemple de sortie de R7 affiche les mêmes informations que pour un routeur de transit standard utilisé dans le chemin principal du LSP : l’adresse d’entrée (192.168.1.1), l’adresse de sortie (192.168.5.1 ) et le nom du LSP (r1-to-r5). Deux chemins de détour sont affichés ; le premier pour éviter R4 (192.168.4.1) et le second pour éviter R2 (192.168.2.1). Parce que R7 est utilisé comme routeur de transit par R2 et R4, R7 peut fusionner les chemins de détour comme indiqué par la valeur identique Label out (100368) pour les deux chemins de détour. S’il R7 reçoit le trafic de R4 avec une valeur d’étiquette de 100736 ou de avec R2 une valeur d’étiquette de 100752, R7 transfère le paquet vers avec R5 une valeur d’étiquette de 100368.

Exemple de sortie

L’exemple de sortie suivant provient de R9, qui est un routeur utilisé dans le chemin de détour dans le réseau indiqué dans Détours de sauvegarde un à un :

Sens

L’exemple de sortie de montre que R9 est l’avant-dernier routeur pour le chemin de R9 déviation, l’itinéraire explicite inclut uniquement l’adresse de la liaison de sortie (10.0.59.1), et la Label out valeur (3) indique qu’il R9 a effectué l’apparition d’étiquettes par avant-dernier saut. De plus, la branche de détour de 10.0.27.1 n’inclut pas d’informations de chemin, car R7 elle a fusionné les chemins de détour de R2 et R4. Notez que la Label out valeur de la branche de détour de 10.0.17.13 est 100368, la même valeur que la Label out valeur de R7.

Exemple de sortie

L’exemple de sortie suivant provient du routeur de sortie R5 dans le réseau indiqué dans Détours de sauvegarde un à un :

Sens

L’exemple de sortie de R5 montre le LSP principal sur le Record route terrain et les détours à travers le réseau.

Vérifiez que le chemin d’accès principal est opérationnel

But

Les chemins principaux doivent toujours être utilisés dans le réseau s’ils sont disponibles. Par conséquent, un LSP revient toujours au chemin principal après une panne, sauf si la configuration est ajustée. Pour plus d’informations sur l’ajustement de la configuration afin d’empêcher le rétablissement d’un chemin principal défaillant, consultez Empêcher l’utilisation d’un chemin qui a précédemment échoué.

Action

Pour vérifier que le chemin d’accès principal est opérationnel, entrez les commandes suivantes en mode opérationnel Junos OS interface de ligne de commande (CLI) :

Sortie de l’échantillon 1

nom_commande

Sortie de l’échantillon 2

nom_commande

Sens

L’exemple de sortie 1 montre que le LSP est opérationnel et utilise le chemin principal (via-r2) avec R2 (10.0.12.14) et R4 (10.0.24.2) comme routeurs de transit. Les valeurs de priorité sont les mêmes pour setup et hold, 6 6. La priorité 0 est la priorité la plus élevée (la meilleure) et 7 est la priorité la plus basse (la pire). La priorité par défaut de configuration et de maintien de Junos OS est 7:0. À moins que certains LSP ne soient plus importants que d’autres, il est recommandé de conserver la valeur par défaut. La configuration d’une priorité d’installation meilleure que la priorité de maintien n’est pas autorisée, ce qui entraîne l’échec de la validation afin d’éviter les boucles de préemption.

Vérifiez que le chemin d’accès secondaire est établi.

But

Lorsque le chemin secondaire est configuré avec l’instruction standby , le chemin secondaire doit être actif , mais pas actif ; il devient actif en cas de défaillance du chemin d’accès principal. Un chemin secondaire configuré sans l’instruction standby ne s’affiche pas à moins que le chemin principal ne tombe en panne. Pour vérifier que le chemin d’accès secondaire est correctement configuré et qu’il s’afficherait en cas de défaillance du chemin d’accès principal, vous devez désactiver un lien ou un nœud critique pour le chemin d’accès principal, puis exécuter la show mpls lsp lsp-path-name extensive commande.

Action

Pour vérifier que le chemin secondaire est établi, entrez la commande suivante en mode opérationnel de l’interface de ligne de commande Junos OS :

Exemple de sortie

Exemple de sortie

nom_commande

L’exemple de sortie suivant montre un chemin secondaire correctement configuré avant et après son affichage. Dans l’exemple, l’interface fe-0/1/0 activée R2 est désactivée, ce qui entraîne l’arrêt du chemin d’accès via-r2principal . Le routeur entrant R1 bascule le trafic vers le chemin via-r7secondaire.

Sens

L’exemple de sortie du routeur de sortie R1 montre un chemin secondaire de secours correctement configuré dans un état inactif, car le chemin principal est toujours actif. Lors de la désactivation d’une interface (interface fe-0/1/0 on R2) critique pour le chemin principal, le chemin via-r2 principal tombe en panne et le chemin via-r7 secondaire de secours se rétablit, ce qui permet R1 de basculer le trafic vers le chemin secondaire de secours.

Vérification de la couche physique

But

Une fois que vous avez configuré le LSP, émis la show mpls lsp extensive commande et déterminé qu’il existe une erreur, vous pouvez commencer à étudier le problème au niveau de la couche physique du réseau.

Figure 3 illustre la couche physique du modèle MPLS en couches.

Figure 3 : Vérification de la couche physiqueVérification de la couche physique

Avec cette couche, vous devez vous assurer que les routeurs sont connectés, que les interfaces sont opérationnelles et configurées correctement sur les routeurs d’entrée, de sortie et de transit.

Si le réseau ne fonctionne pas au niveau de cette couche, le chemin de commutation d’étiquettes (LSP) ne fonctionne pas comme configuré.

Figure 4 illustre le réseau MPLS et le problème décrit dans cette rubrique.

Figure 4 : Réseau MPLS brisé au niveau de la couche physiqueRéseau MPLS brisé au niveau de la couche physique

Le réseau illustré ci-dessous Figure 4 est une configuration entièrement maillée dans laquelle chaque interface directement connectée peut recevoir et envoyer des paquets à toutes les autres interfaces similaires. Le LSP de ce réseau est configuré pour fonctionner depuis le routeur R1entrant , via le routeur R3de transit , jusqu’au routeur de sortie R6. En outre, un LSP inverse est configuré pour s’exécuter de A R3R1à R6 , créant ainsi un trafic bidirectionnel.

Toutefois, dans cet exemple, le trafic n’utilise pas le LSP configuré. Au lieu de cela, le trafic utilise l’itinéraire alternatif de R1 through R2 à R6, et dans le sens inverse, de R6 through R5 to R1through .

Lorsque vous avez connaissance d’une situation dans laquelle une autre route est utilisée au lieu du LSP configuré, vérifiez que la couche physique fonctionne correctement. Vous constaterez peut-être que les routeurs ne sont pas connectés ou que les interfaces ne sont pas opérationnelles et configurées correctement sur les routeurs d’entrée, de sortie ou de transit.

La croix illustrée en Figure 4 indique où le LSP est cassé en raison d’une erreur de configuration sur le routeur entrant R1.

Pour vérifier la couche physique, procédez comme suit :

Vérifier le LSP

But

En règle générale, vous utilisez la show mpls lsp extensive commande pour vérifier le LSP. Toutefois, pour une vérification rapide de l’état LSP, utilisez la show mpls lsp commande. Si le LSP est en panne, utilisez l’option extensive (show mpls lsp extensive) comme suivi. Si votre réseau compte de nombreux LSP, vous pouvez envisager de spécifier le nom du fournisseur de services linguistiques à l’aide de l’option name (show mpls lsp name name ou show mpls lsp name name extensive).

Action

Pour déterminer si le LSP est actif, entrez la commande suivante à partir du routeur entrant :

Exemple de sortie
nom_commande

Sens

L’exemple de sortie du routeur entrant R1 montre que le LSP utilise un autre chemin plutôt que le chemin configuré. Le chemin configuré pour le LSP est R1 vers R3R6, et pour le LSP inverse, R6 jusqu’à R1R3 . Le chemin alternatif utilisé par le LSP est R1 à R6, travers R2 et pour le LSP inverse, R6 t hrough R5 à R1.

Vérifier la connexion du routeur

But

Vérifiez que les routeurs entrants, de transit et de sortie appropriés fonctionnent en vérifiant si les paquets ont été reçus et transmis avec une perte de paquets de 0 %.

Action

Pour déterminer que les routeurs sont connectés, entrez la commande suivante à partir des routeurs d’entrée et de transit :

Exemple de sortie
nom_commande

Sens

L’exemple de sortie montre que le routeur entrant R1 reçoit des paquets du routeur R3de transit et que le routeur de transit reçoit des paquets du routeur de sortie. Par conséquent, les routeurs du LSP sont connectés.

Vérifier les interfaces

But

Vérifiez que les interfaces sont correctement configurées à l’aide de l’instruction family mpls .

Action

Pour déterminer si les interfaces concernées sont actives et configurées correctement, entrez les commandes suivantes à partir des routeurs entrants, de transit et de sortie :

Exemple de sortie
nom_commande

Sens

L’exemple de sortie montre que l’instruction n’est pas configurée au niveau hiérarchique [edit interfaces type-fpc/pic/port] de l’interface so-0/0/2.0family mpls sur le routeur entrant, ce qui indique que l’interface n’est pas correctement configurée pour prendre en charge le LSP. Le LSP est correctement configuré au niveau de la hiérarchie [edit protocols mpls].

La sortie des routeurs de transit et de sortie (non illustrée) indique que les interfaces de ces routeurs sont correctement configurées.

Prendre les mesures qui s’imposent

Problème

Description

En fonction de l’erreur que vous avez rencontrée lors de votre investigation, vous devez prendre les mesures appropriées pour corriger le problème. Dans l’exemple ci-dessous, l’instruction family mpls , qui était manquante, est incluse dans la configuration du routeur entrant R1.

Solution

Pour corriger l’erreur dans cet exemple, entrez les commandes suivantes :

Exemple de sortie
Sens

L’exemple de sortie du routeur entrant R1 montre que l’instruction family mpls est correctement configurée pour l’interface so-0/0/2.0et que le LSP fonctionne maintenant comme configuré à l’origine.

Vérifiez à nouveau le LSP

But

Après avoir pris les mesures appropriées pour corriger l’erreur, le LSP doit être vérifié à nouveau pour confirmer que le problème dans la couche physique a été résolu.

Action

Pour vérifier que le LSP est opérationnel et qu’il traverse le réseau comme prévu, entrez la commande suivante :

Sortie de l’échantillon 1
nom_commande
Sortie de l’échantillon 2
nom_commande

Sens

L’exemple de sortie 1 du routeur entrant R1 montre que le LSP traverse maintenant le réseau le long du chemin attendu, de R1 à , R3 R6et le LSP inverse, de R6 à .R3R1

L’exemple de sortie 2 du routeur entrant R1 montre que le LSP est forcé de prendre le chemin prévu car MPLS est désactivé sur R1 les interfaces so-0/0/0.0 et so-0/0/1.0. Si ces interfaces n’étaient pas désactivées, même si la configuration est désormais correcte, le LSP traverserait toujours le réseau via l’autre chemin.

Vérification des couches IP et IGP

Problème

Description

Une fois que vous avez configuré le chemin de commutation d’étiquettes (LSP), émis la show mpls lsp extensive commande et déterminé qu’il existe une erreur, vous constaterez peut-être que l’erreur ne se trouve pas dans les couches physiques ou de liaison de données. Continuez à étudier le problème au niveau des couches IP et IGP du réseau.

Figure 7 illustre les couches IP et IGP du modèle MPLS en couches.

Figure 7 : Couches IP et IGPCouches IP et IGP

Solution

Au niveau des couches IP et IGP, vous devez vérifier les points suivants :

  • Les interfaces ont un adressage IP correct et les voisins ou proximités IGP sont établis.

  • Les protocoles OSPF (Open Shortest Path First) ou IS-IS (Intermediate System-to-Intermediate System) sont configurés et fonctionnent correctement.

    • Si le protocole OSPF est configuré, vérifiez d’abord la couche IP, puis la configuration OSPF, en vous assurant que le protocole, les interfaces et l'ingénierie de trafic sont correctement configurés.

    • Si le protocole IS-IS est configuré, peu importe que vous vérifiiez d’abord IS-IS ou IP, car les deux protocoles sont indépendants l’un de l’autre. Vérifiez que les proximités IS-IS sont actives et que les interfaces et le protocole IS-IS sont correctement configurés.

      REMARQUE :

      L’ingénierie du trafic du protocole IS-IS est activée par défaut.

Si le réseau ne fonctionne pas au niveau des couches IP ou IGP, le LSP ne fonctionne pas comme configuré.

Figure 8 illustre le réseau MPLS utilisé dans cette rubrique.

Figure 8 : Réseau MPLS cassé au niveau des couches IP et IGPRéseau MPLS cassé au niveau des couches IP et IGP

Le réseau illustré ci-dessous Figure 8 est une configuration entièrement maillée dans laquelle chaque interface directement connectée peut recevoir et envoyer des paquets à toutes les autres interfaces similaires. Le LSP de ce réseau est configuré pour fonctionner depuis le routeur R1entrant , via le routeur R3de transit , jusqu’au routeur de sortie R6. En outre, un LSP inverse est configuré pour s’exécuter de R6, à , R3à , créant R1ainsi un trafic bidirectionnel. Les croisements indiquent Figure 8 les endroits où le LSP ne fonctionne pas en raison des problèmes suivants au niveau des couches IP et IGP :

  • Une adresse IP est mal configurée sur le routeur entrant (R1).

  • Le protocole OSPF est configuré avec un ID de routeur (RID) mais sans l’interface de bouclage (lo0), et l’ingénierie du trafic est absente du routeur de transit (R3).

  • Les niveaux dans le réseau IS-IS ne correspondent pas.

Vérification de la couche IP

But

Vous pouvez vérifier la couche IP avant ou après avoir vérifié la couche IGP (Interior Gateway Protocol), selon qu’OSPF ou IS-IS est configuré en tant qu’IGP. Si votre réseau MPLS est configuré avec OSPF comme IGP, vous devez d’abord vérifier la couche IP, en vérifiant que les interfaces ont un adressage IP correct et que les voisins OSPF sont établis avant de vérifier la couche OSPF.

Si IS-IS est configuré en tant qu’IGP dans votre réseau MPLS, vous pouvez d’abord vérifier la couche IP ou la couche de protocole IS-IS. L’ordre dans lequel vous vérifiez la couche IP ou IS-IS n’affecte pas les résultats.

Figure 9 : Réseau MPLS défaillant au niveau de la couche IPRéseau MPLS défaillant au niveau de la couche IP

La croix indique Figure 9 où le LSP est cassé en raison de la configuration incorrecte d’une adresse IP sur le routeur entrant R1.

Vérifier le LSP

But

Après avoir configuré le LSP, vous devez vérifier qu’il est actif. Il peut s’agir d’un LSP entrant, de transit ou de sortie. Utilisez la show mpls lsp commande pour une vérification rapide de l’état du LSP, avec l’option extensive (show mpls lsp extensive) en tant que suivi si le LSP est en panne. Si votre réseau comporte de nombreux LSP, vous pouvez envisager de spécifier le nom du LSP à l’aide de l’option name (show mpls lsp name name ou show mpls lsp name name extensive).

Action

Pour vérifier que le LSP est actif, entrez la commande suivante à partir du routeur entrant :

Sortie de l’échantillon 1
nom_commande

Sens

L’exemple de sortie du routeur entrant R1 montre qu’un échec d’attribution d’étiquette MPLS s’est produit et que l’algorithme CSPF (Constrained Shortest Path First) a échoué, ce qui a entraîné l’absence de route vers la destination 10.0.0.6 le R6.

Vérifier l’adressage IP

But

Lorsque vous examinez la couche IP, vous vérifiez que les interfaces ont un adressage IP correct et que des voisins OSPF ou des contiguïtés IS-IS sont établis. Dans cet exemple, une adresse IP est mal configurée sur le routeur entrant (R1).

Action

Pour vérifier l’adressage IP, entrez la commande suivante à partir des routeurs entrants, de transit et de sortie :

Exemple de sortie
nom_commande

Sens

L’exemple de sortie montre que les adresses IP de l’interface so-0/0/2.0 activée R1 et de l’interface so-0/0/2.0 activée R3 sont identiques. Les adresses IP d’interface au sein d’un réseau doivent être uniques pour que l’interface soit identifiée correctement.

Vérifier les voisins ou les proximités au niveau de la couche IP

But

Si l’adressage IP n’est pas configuré correctement, les voisins OSPF ou les contiguïtés IS-IS doivent tous deux être vérifiés pour déterminer si l’un d’entre eux ou les deux sont établis.

Action

Pour vérifier les voisins (OSPF) ou les proximités (IS-IS), entrez les commandes suivantes à partir des routeurs entrants, de transit et de sortie :

Sortie de l’échantillon 1
nom_commande
Sortie de l’échantillon 2
nom_commande

Sens

L’exemple de sortie 1 des routeurs entrants, de transit et de sortie montre que R1 et R3 ne sont pas des voisins OSPF établis. Étant donné que les deux interfaces so-0/0/2.0 (R1 et R3) sont configurées avec des adresses IP identiques, on peut s’y attendre. Le protocole OSPF achemine les paquets IP en se basant uniquement sur l’adresse IP de destination contenue dans l’en-tête du paquet IP. Par conséquent, des adresses IP identiques dans le système autonome (AS) font que les voisins ne s’établissent pas.

L’exemple de sortie 2 des routeurs entrants, de transit et de sortie montre que R1 et R3 ont établi une contiguïté IS-IS malgré les adresses IP identiques configurées sur les interfaces so-0/0/2.0 sur R1 et R3. Le protocole IS-IS se comporte différemment du protocole OSPF, car il ne s’appuie pas sur IP pour établir une contiguïté. Toutefois, si le LSP n’est pas opérationnel, il est toujours utile de vérifier l’adressage du sous-réseau IP au cas où il y aurait une erreur dans cette couche. La correction de l’erreur d’adressage peut faire apparaître le LSP.

Prendre les mesures qui s’imposent

Problème

Description

En fonction de l’erreur que vous avez rencontrée lors de votre investigation, vous devez prendre les mesures appropriées pour corriger le problème. Dans cet exemple, l’adresse IP d’une interface sur le routeur R2 de transit n’est pas correctement configurée.

Solution

Pour corriger l’erreur dans cet exemple, entrez les commandes suivantes :

Exemple de sortie
Sens

L’exemple de sortie montre que l’interface so-0/0/2 sur le routeur entrant R1 est maintenant configurée avec l’adresse IP correcte. Cette correction se traduit par des adresses IP de sous-réseau uniques pour toutes les interfaces du réseau MPLS dans Réseau MPLS cassé au niveau des couches IP et IGP, et la possibilité que le LSP puisse apparaître.

Vérifiez à nouveau le LSP

But

Après avoir pris les mesures appropriées pour corriger l’erreur, le LSP doit être vérifié à nouveau pour confirmer que le problème dans le protocole OSPF a été résolu.

Action

Pour vérifier à nouveau le LSP, entrez la commande suivante sur les routeurs d’entrée, de transit et de sortie :

Sortie de l’échantillon 1
nom_commande
Sortie de l’échantillon 2
nom_commande
Sortie de l’échantillon 3
nom_commande

Sens

L’exemple de sortie 1 du routeur entrant R1 montre que LSP R1-to-R6 a une route active vers R6 et que l’état est actif. La sortie indique que la session R6-to-R1 LSP sortante a reçu et envoyé une étiquette de récupération.

L’exemple de sortie 2 du routeur R3 de transit montre qu’il existe deux sessions LSP de transit, l’une de R1 vers et R6 l’autre de R6 vers Les R1. deux LSP sont actifs.

L’exemple de sortie 3 du routeur de sortie R6 montre que le LSP est actif et que l’itinéraire actif est l’itinéraire principal. Le LSP traverse maintenant le réseau le long du chemin attendu, de R1 à , R3 R6et le LSP inverse, de R6 à travers R3 vers R1.

Vérifiez à nouveau le LSP

But

Après avoir pris les mesures appropriées pour corriger l’erreur, le LSP doit être vérifié à nouveau pour confirmer que le problème dans le protocole IS-IS a été résolu.

Action

Pour vérifier que le LSP est opérationnel et qu’il traverse le réseau comme prévu, entrez la commande suivante à partir des routeurs d’entrée, de sortie et de transit :

Exemple de sortie

nom_commande

Sens

L’exemple de sortie du routeur entrant R1 et du routeur de sortie R6 montre que le LSP traverse maintenant le réseau le long du chemin attendu, de R1 à , R6R3 et le LSP inverse, de R6 à .R3R1 En outre, l’exemple de sortie du routeur R3 de transit montre qu’il existe deux sessions LSP de transit, l’une de R1 à R6, et l’autre de R6 à .R1

Vérification de la couche RSVP

But

Une fois que vous avez configuré le chemin de commutation d’étiquettes (LSP), émis la show mpls lsp extensive commande et déterminé qu’il existe une erreur, vous constaterez peut-être que l’erreur ne se trouve pas dans les couches physiques, de liaison de données ou de protocole Internet (IP) et IGP (Interior Gateway Protocol). Poursuivez l’examen du problème au niveau de la couche RSVP du réseau.

Figure 10 illustre la couche RSVP du modèle MPLS en couches.

Figure 10 : Vérification de la couche RSVPVérification de la couche RSVP

Avec cette couche, vous vérifiez que la signalisation RSVP dynamique se produit comme prévu, que les voisins sont connectés et que les interfaces sont correctement configurées pour RSVP. Vérifiez les routeurs d’entrée, de sortie et de transit.

Si le réseau ne fonctionne pas au niveau de cette couche, le LSP ne fonctionne pas comme configuré.

Figure 11 illustre le réseau MPLS utilisé dans cette rubrique.

Figure 11 : Réseau MPLS interrompu au niveau de la couche RSVPRéseau MPLS interrompu au niveau de la couche RSVP

Le réseau illustré ci-dessous Figure 11 est une configuration entièrement maillée dans laquelle chaque interface directement connectée peut recevoir et envoyer des paquets à toutes les autres interfaces similaires. Le LSP de ce réseau est configuré pour fonctionner depuis le routeur R1entrant , via le routeur R3de transit , jusqu’au routeur de sortie R6. En outre, un LSP inverse est configuré pour s’exécuter de A R3R1à R6 , créant ainsi un trafic bidirectionnel.

Toutefois, dans cet exemple, le LSP est vers le bas sans chemin dans l’une ou l’autre direction, de R1 vers R6 ou de R6 vers R1.

Les croix illustrées en Figure 11 indiquent l’endroit où le LSP est brisé. Parmi les raisons possibles pour lesquelles le LSP est cassé, citons le fait que la signalisation dynamique RSVP ne se produit pas comme prévu, que les voisins ne sont pas connectés ou que les interfaces ne sont pas correctement configurées pour RSVP.

Dans le réseau de Figure 11, une erreur de configuration sur le routeur R3 de transit empêche le LSP de traverser le réseau comme prévu.

Pour vérifier la couche RSVP, procédez comme suit :

Vérifier le LSP

But

En règle générale, vous utilisez la show mpls lsp extensive commande pour vérifier le LSP. Toutefois, pour une vérification rapide de l’état du LSP, utilisez la show mpls lsp commande. Si le LSP est en panne, utilisez l’option extensive (show mpls lsp extensive) comme suivi. Si votre réseau compte de nombreux LSP, vous pouvez envisager de spécifier le nom du fournisseur de services linguistiques à l’aide de l’option name (show mpls lsp name name ou show mpls lsp name name extensive).

Action

Pour déterminer si le LSP est actif, entrez la commande suivante à partir du routeur entrant :

Sortie de l’échantillon 1
nom_commande

Sens

L’exemple de sortie montre que le LSP est vers le bas dans les deux sens, de R1 à R6, et de R6 à .R1 La sortie de R1 montre qu’il R1 s’agit d’un LSP no-cspf puisqu’il a essayé d’émettre l’appel sans être en mesure d’atteindre la destination. La sortie de montre que l’algorithme CSPF (Constrained Shortest Path First) a échoué, ce qui a entraîné l’absence d’itinéraire R6 vers la destination 10.0.0.1.

Vérifier les sessions de réponses

But

Lorsqu’une session RSVP est créée avec succès, le LSP est configuré le long des chemins créés par la session RSVP. Si la session RSVP échoue, le LSP ne fonctionne pas comme configuré.

Action

Pour vérifier les sessions RSVP actuellement actives, entrez la commande suivante à partir des routeurs entrants, de transit et de sortie :

Sortie de l’échantillon 1
nom_commande
Sortie de l’échantillon 2
nom_commande

Sens

L’exemple de sortie 1 de tous les routeurs montre qu’aucune session RSVP n’a été créée avec succès, même si le LSP R6-to-R1 est configuré.

Contrairement à l’exemple de sortie 1 et pour illustrer la sortie correcte, l’exemple de sortie 2 montre la sortie des routeurs d’entrée, de transit et de sortie lorsque la configuration RSVP est correcte et que le LSP traverse le réseau comme configuré. R1 et R6 les deux montrent une session RSVP entrante et sortante, avec le LSP R1-to-R6, et le LSP R6-to-R1inverse . Le routeur R3 de transit affiche deux sessions de RSVP de transit.

Vérifier les voisins RSVP

But

Affichez la liste des voisins RSVP qui ont été appris dynamiquement lors de l’échange de paquets RSVP. Une fois qu’un voisin est appris, il n’est jamais supprimé de la liste des voisins RSVP, sauf si la configuration RSVP est supprimée du routeur.

Action

Pour vérifier les voisins RSVP, entrez la commande suivante à partir des routeurs d’entrée, de transit et de sortie :

Sortie de l’échantillon 1
nom_commande
Sortie de l’échantillon 2
nom_commande

Sens

L’exemple de sortie 1 montre que R1 et R6 ont chacun un voisin RSVP, R3. Cependant, les valeurs du Up/Dn champ sont différentes. R1 a une valeur de 1/0 et R6 a une valeur de 1/1, ce qui indique que R1 est un voisin actif avec R3, mais R6 ne l’est pas. Lorsque le nombre de vers le haut est supérieur d’un à celui vers le bas, le voisin est actif ; Si les valeurs sont égales, le voisin est en panne. Les valeurs de sont R6 égales, 1/1, ce qui indique que le voisin R3 est en panne.

Le routeur R3 de transit connaît l’existence de deux voisins, R1 et R6. Le Up/Dn champ indique qu’il s’agit d’un voisin actif et R6 qu’il R1 est en panne. À ce stade, il n’est pas possible de déterminer si le problème réside dans R3 ou R6, car les deux voisins ne sont pas actifs.

Contrairement à l’exemple de sortie 1 et pour illustrer la sortie correcte, l’exemple de sortie 2 montre la relation de voisinage correcte entre le routeur R3 de transit et le routeur de sortie R6. Le Up/Dn champ indique que le nombre de points positifs est supérieur d’un à celui des nombres inférieurs, 1/0ce qui indique que les voisins sont actifs.

Vérifier les interfaces RSVP

But

Affichez l’état de chaque interface sur laquelle RSVP est activé pour déterminer où l’erreur de configuration s’est produite.

Action

Pour vérifier l’état des interfaces RSVP, entrez la commande suivante à partir des routeurs entrants, de transit et de sortie :

Sortie de l’échantillon 1
nom_commande
Sortie de l’échantillon 2
nom_commande

Sens

L’exemple de sortie 1 montre que même si chaque routeur a des interfaces actives et que RSVP est actif, il n’y a aucune réservation (Active resv) sur aucun des routeurs. Dans cet exemple, nous nous attendons à au moins une réservation sur les routeurs d’entrée et de sortie, et deux réservations sur le routeur de transit.

De plus, l’interface so-0/0/3 sur le routeur R3 de transit n’est pas incluse dans la configuration. L’inclusion de cette interface est essentielle au succès du LSP.

Contrairement à l’exemple de sortie 1 et pour illustrer une sortie correcte, l’exemple de sortie 2 montre les interfaces pertinentes avec des réservations actives.

Vérifier la configuration du protocole RSVP

But

Une fois que vous avez vérifié les sessions RSVP, les interfaces, les voisins et déterminé qu’il pourrait y avoir une erreur de configuration, vérifiez la configuration du protocole RSVP.

Action

Pour vérifier la configuration RSVP, entrez la commande suivante à partir des routeurs entrants, de transit et de sortie :

Exemple de sortie
nom_commande

Sens

L’exemple de sortie montre qu’il R3 manque une interface so-0/0/3.0 dans la configuration du protocole RSVP. Cette interface est essentielle au bon fonctionnement du LSP.

Prendre les mesures qui s’imposent

Problème

Description

En fonction de l’erreur que vous avez rencontrée lors de votre investigation, vous devez prendre les mesures appropriées pour corriger le problème. Dans cet exemple, il manque une interface dans la configuration du routeur R3.

Solution

Pour corriger l’erreur dans cet exemple, procédez comme suit :

  1. Incluez l’interface manquante dans la configuration du routeur de transit R3 :

  2. Vérifiez et validez la configuration :

Exemple de sortie
Sens

L’exemple de sortie montre que l’interface so-0/0/3.0 manquante sur le routeur R3 de transit est désormais correctement incluse au niveau de la hiérarchie [edit protocols rsvp]. Il en résulte la possibilité que le LSP puisse apparaître.

Vérifiez à nouveau le LSP

But

Après avoir pris les mesures appropriées pour corriger l’erreur, le LSP doit être vérifié à nouveau pour confirmer que le problème dans la couche MPLS a été résolu.

Action

Pour vérifier à nouveau le LSP, entrez la commande suivante sur les routeurs d’entrée, de transit et de sortie :

Sortie de l’échantillon 1
nom_commande
Sortie de l’échantillon 2
nom_commande
Sortie de l’échantillon 3
nom_commande

Sens

L’exemple de sortie 1 du routeur entrant R1 montre que LSP R1-to-R6 a une route active vers R6 et que l’état est actif.

L’exemple de sortie 2 du routeur R3 de transit montre qu’il existe deux sessions LSP de transit, l’une de R1 vers et R6 l’autre de R6 vers R1. Les deux LSP sont en hausse.

L’exemple de sortie 3 du routeur de sortie R6 montre que le LSP est actif et que l’itinéraire actif est l’itinéraire principal. Le LSP traverse maintenant le réseau le long du chemin attendu, de R1 à , R3R6et le LSP inverse, de R6 à travers R3 vers R1.

Détermination des statistiques LSP

But

Affichez des informations détaillées sur les objets RSVP pour faciliter le diagnostic d’un problème LSP.

Action

Pour vérifier les objets RSVP, entrez la commande suivante en mode opérationnel de l’interface de ligne de commande Junos OS :

Exemple de sortie

nom_commande

Sens

L’exemple de sortie montre qu’il existe une session RSVP entrante et une session RSVP sortante. L’adresse source de la session entrante est 10.0.0.1 (R1) et la session est active, avec une route active. Le nom LSP est R1-to-R6 et c’est le chemin principal pour le LSP.

L’étiquette de récupération (100064) est envoyée par un routeur de redémarrage normal à son voisin pour récupérer un état de transfert. Il s’agit probablement de l’ancienne étiquette annoncée par le routeur avant qu’il ne tombe en panne.

Cette session utilise le filtre fixe (FF) style de réservation (Resv style). Comme il s’agit d’un routeur entrant, il n’y a pas d’étiquette entrante. L’étiquette de sortie (fournie par le routeur suivant en aval) est 100064.

Le Time Left champ indique le nombre de secondes restantes dans la session RSVP, et l’objet Tspec fournit des informations sur le taux de charge contrôlé (rate) et la taille de rafale maximale (peak), une valeur infinie (Infbps) pour l’option de livraison garantie, et l’indication que les paquets inférieurs à 20 octets sont traités comme 20 octets, tandis que les paquets supérieurs à 1500 octets sont traités comme 1500 octets.

Le numéro de port est l’ID de tunnel IPv4, tandis que le numéro de port de l’expéditeur/récepteur est l’ID LSP. L’ID de tunnel IPv4 est unique pendant toute la durée de vie du LSP, tandis que l’ID LSP de l’expéditeur/récepteur peut changer, par exemple, avec une réservation de style SE.

Le PATH rcvfrom champ inclut la source du message de chemin. Puisqu’il s’agit du routeur entrant, le client local est à l’origine du message de chemin.

Le PATH sentto champ inclut le chemin d’accès, le message de destination, (10.1.13.2) et l’interface sortante (so-0/0/2.0). Le RESV rcvfrom champ comprend à la fois la source du message Resv reçu (10.1.13.2) et l’interface entrante (so-0/0/2.0).

Les valeurs de l’itinéraire explicite RSVP et de l’enregistrement de l’itinéraire sont identiques : 10.1.13.2 et 10.1.36.2. Dans la plupart des cas, les valeurs d’itinéraire explicite et d’itinéraire d’enregistrement sont identiques. Les différences indiquent qu’un certain reroutage de chemin s’est produit, généralement lors du reroutage rapide.

Les Total champs indiquent le nombre total de sessions RSVP entrantes, sortantes et de transit, le total étant égal à la somme des sessions montantes et descendantes. Dans cet exemple, il existe une session d’entrée, une session de sortie et aucune session de RSVP de transit.

Vérification de l’utilisation des LSP dans votre réseau

But

Lorsque vous vérifiez l’utilisation valide d’un LSP sur les routeurs d’entrée et de transit de votre réseau, vous pouvez déterminer s’il existe un problème avec MPLS (Multiprotocol Label Switching) dans votre réseau. Figure 12 Décrit l’exemple de réseau utilisé dans cette rubrique.

Figure 12 : Topologie MPLS pour la vérification de l’utilisation des LSPTopologie MPLS pour la vérification de l’utilisation des LSP

Le réseau MPLS en Figure 12 illustre un réseau de routeur uniquement avec des interfaces SONET qui se composent des composants suivants :

  • Une topologie interne entièrement maillée Border Gateway Protocol (IBGP), utilisant AS 65432

  • MPLS et Resource Reservation Protocol (RSVP) activés sur tous les routeurs

  • Une send-statics politique sur les routeurs R1 et R6 qui permet d’annoncer une nouvelle route dans le réseau

  • Un LSP entre les routeurs R1 et R6

Le réseau illustré en Figure 12 est un réseau maillé complet Border Gateway Protocol (BGP). Étant donné que les réflecteurs de route et les confédérations ne sont pas utilisés pour propager les routes BGP apprises, chaque routeur doit avoir une session BGP avec tous les autres routeurs exécutant BGP.

Pour vérifier l’utilisation du LSP sur votre réseau, procédez comme suit :

Vérification d’un LSP sur le routeur entrant

But

Vous pouvez vérifier la disponibilité d’un LSP lorsqu’il est actif en examinant la inet.3 table de routage sur le routeur entrant. La inet.3 table de routage contient l’adresse hôte du routeur de sortie de chaque LSP. Cette table de routage est utilisée sur les routeurs entrants pour acheminer les paquets BGP vers le routeur de sortie de destination. BGP utilise la inet.3 table de routage du routeur entrant pour résoudre les adresses de saut suivant.

Action

Pour vérifier un LSP sur un routeur entrant, entrez la commande suivante Junos OS mode opérationnel de l’interface de ligne de commande (CLI) :

Exemple de sortie
nom_commande

Sens

L’exemple de sortie montre la inet.3 table de routage. Par défaut, seuls les réseaux privés virtuels (VPN) BGP et MPLS peuvent utiliser la table de routage pour résoudre les inet.3 informations de saut suivant. Une destination est répertoriée dans la table de routage, 10.0.0.6. Cette destination (10.0.0.6) est signalée par RSVP et correspond au chemin actif actuel, comme indiqué par l’astérisque (*). La préférence de protocole pour cette route est 7, et la métrique qui lui est associée est 20. Le chemin de commutation d’étiquettes est R1-to-R6, via l’interface so-0/0/2.0, qui est l’interface physique de transit du saut suivant.

En règle générale, l’avant-dernier routeur du LSP affiche l’étiquette du paquet ou la remet en valeur 0. Si l’avant-dernier routeur affiche l’étiquette supérieure et qu’un paquet IPv4 se trouve en dessous, le routeur de sortie achemine le paquet IPv4 en consultant la table de routage inet.0 IP pour déterminer comment transférer le paquet. Si un autre type d’étiquette (par exemple, une étiquette créée par un tunnel LDP (Label Distribution Protocol) ou des VPN, mais pas IPv4) se trouve sous l’étiquette supérieure, le routeur de sortie n’examine pas la inet.0 table de routage. Au lieu de cela, il examine la mpls.0 table de routage pour les décisions de transfert.

Si l’avant-dernier routeur remet l’étiquette du paquet à 0, l’routeur de sortie enlève l’étiquette 0, indiquant qu’un paquet IPv4 suit. Le paquet est examiné par la inet.0 table de routage pour les décisions de transfert.

Lorsqu’un routeur de sortie de transit reçoit un paquet MPLS, les informations contenues dans le table de transfert MPLS sont utilisées pour déterminer le prochain routeur de transit dans le LSP ou pour déterminer si ce routeur est le routeur de sortie.

Lorsque BGP résout un préfixe de saut suivant, il examine à la fois les tables de routage et inet.3 et inet.0 recherche le saut suivant avec la préférence la plus faible ; par exemple, la préférence RSVP 7 est préférée à la préférence OSPF 10. Le LSP signalé RSVP est utilisé pour atteindre le saut suivant BGP. Il s’agit de l’option par défaut lorsque le saut suivant BGP est égal à l’adresse de sortie LSP. Une fois le tronçon suivant BGP résolu par le biais d’un LSP, le trafic BGP utilise le LSP pour transférer le trafic de transit BGP.

Vérification d’un LSP sur un routeur de transit

But

Vous pouvez vérifier la disponibilité d’un LSP lorsqu’il est actif en examinant la mpls.0 table de routage sur un routeur de transit. MPLS gère la mpls.0 table de routage, qui contient la liste du prochain routeur à commutation d’étiquettes dans chaque LSP. Cette table de routage est utilisée sur les routeurs de transit pour acheminer les paquets vers le routeur suivant le long d’un LSP.

Action

Pour vérifier un LSP sur un routeur de transit, entrez la commande suivante en mode opérationnel de l’interface de ligne de commande Junos OS :

Exemple de sortie
nom_commande

Sens

L’exemple de sortie du routeur R3 de transit affiche les entrées d’itinéraire sous la forme d’entrées d’étiquettes MPLS, ce qui indique qu’il n’y a qu’une seule route active, même s’il y a cinq entrées actives.

Les trois premières étiquettes MPLS sont des étiquettes MPLS réservées définies dans la RFC 3032. Les paquets reçus avec ces valeurs d’étiquette sont envoyés au moteur de routage pour traitement. L’étiquette 0 est l’étiquette nulle explicite IPv4. L’étiquette 1 est l’équivalent MPLS de l’étiquette d’alerte de routeur IP et l’étiquette 2 est l’étiquette NULL explicite IPv6.

Les deux entrées avec l’étiquette 100064 sont pour le même LSP, R1-to-R6. Il y a deux entrées car les valeurs de pile dans l’en-tête MPLS peuvent être différentes. La deuxième entrée, 100064 (S=0), indique que la profondeur de la pile n’est pas égale à 1 et que des valeurs d’étiquette supplémentaires sont incluses dans le paquet. En revanche, la première entrée de 100064 a un S=1 déduit qui indique une profondeur de pile de 1 et en fait la dernière étiquette du paquet. La double entrée indique qu’il s’agit de l’avant-dernier routeur. Pour plus d’informations sur l’empilage d’étiquettes MPLS, reportez-vous à la RFC 3032, Codage d’empilement d’étiquettes MPLS.

L’étiquette entrante est l’en-tête MPLS du paquet MPLS et est attribuée par RSVP au voisin en amont. Les routeurs Juniper Networks attribuent dynamiquement des étiquettes aux LSP RSVP issus de l’ingénierie du trafic compris entre 100 000 et 1 048 575.

Le routeur attribue des étiquettes à partir de l’étiquette 100 000, par incréments de 16. La séquence d’affectation des étiquettes est 100 000, 100 016, 100 032, 100 048, etc. À la fin des étiquettes attribuées, les numéros d’étiquettes recommencent à 100001, en s’incrémentant par unités de 16. Juniper Networks réserve les étiquettes à diverses fins. Tableau 1 Répertorie les différentes attributions de plage d’étiquettes pour les étiquettes entrantes.

Tableau 1 : Attributions de plages d’étiquettes MPLS

Étiquette entrante

Statut

0 par 15

Réservé par l’IETF

16 par 1023

Réservé à l’affectation LSP statique

1024 par 9999

Réservé à un usage interne (par exemple, étiquettes CCC)

10,000 par 99,999

Réservé à l’affectation LSP statique

100,000 par 1,048,575

Réservé à l’attribution dynamique d’étiquettes

Vérifiez que l’équilibrage de charge fonctionne

But

Après avoir configuré l’équilibrage de charge, vérifiez que la charge du trafic est équilibrée de manière égale entre les chemins. Dans cette section, la sortie de la commande reflète la configuration d’équilibrage de charge de l’exemple de réseau illustré dans Topologie de réseau d’équilibrage de charge. Les clear commandes sont utilisées pour remettre à zéro le LSP et les compteurs d’interface afin que les valeurs reflètent le fonctionnement de la configuration d’équilibrage de charge.

Action

Pour vérifier l’équilibrage de charge entre les interfaces et les LSP, utilisez la commande suivante sur le routeur entrant :

Pour vérifier l’équilibrage de charge entre les interfaces et les LSP, utilisez les commandes suivantes sur un routeur de transit :

Exemple de sortie

nom_commande

L’exemple de sortie suivant concerne la configuration sur le routeur entrant R1:

Sens

L’exemple de sortie de la commande sur le show configuration routeur entrant R1 montre que l’équilibrage de charge est correctement configuré avec l’instruction lbpp de stratégie. En outre, la lbpp stratégie est exportée dans la table de transfert au niveau de la [edit routing-options] hiérarchie.

Exemple de sortie

L’exemple de sortie suivant provient du routeur de transit R2 :

Sens

L’exemple de sortie de la commande émise sur le show route routeur R2 de transit montre les deux chemins à coût égal (so-0/0/1 et so-0/0/2) à travers le réseau jusqu’à l’adresse de bouclage vers R0 (192.168.0.1). Même si le crochet d’angle droit (>) indique généralement la route active, dans ce cas, ce n’est pas le cas, comme le montrent les quatre exemples de sortie suivants.

Exemple de sortie

L’exemple de sortie suivant provient du routeur de transit R2 :

Sens

L’exemple de sortie de la monitor interface traffic commande émise sur le routeur R2 de transit montre que le trafic de sortie est uniformément réparti sur les deux interfaces so-0/0/1 et so-0/0/2.

Exemple de sortie

L’exemple de sortie suivant provient du routeur de transit R2 :

Sens

L’exemple de sortie de la commande émise sur le show mpls lsp statistics routeur R2 de transit montre que le trafic de sortie est uniformément réparti sur les quatre LSP configurés sur le routeur entrant R6.

Exemple de sortie

L’exemple de sortie suivant provient du routeur de transit R2 :

Sens

L’exemple de sortie de la commande émise sur le show route forwarding-table destination routeur R2 de transit s’affiche ulst dans le champ, ce qui indique que l’équilibrage Type de charge fonctionne. Les deux entrées unicast (ucst) dans le Type champ sont les deux sauts suivants pour les LSP.

Exemple de sortie

L’exemple de sortie suivant provient du routeur de transit R2 :

Sens

L’exemple de sortie de la commande émise sur le show route forwarding-table | find mpls routeur de transit R2 montre la table de routage MPLS qui contient les étiquettes reçues et utilisées par ce routeur pour transférer les paquets au routeur de saut suivant. Cette table de routage est principalement utilisée sur les routeurs de transit pour acheminer les paquets vers le routeur suivant le long d’un LSP. Les trois premières étiquettes de la Destination colonne (Étiquette 0, Étiquette 1 et Étiquette 2) sont automatiquement saisies par MPLS lorsque le protocole est activé. Ces étiquettes sont des étiquettes MPLS réservées définies dans la RFC 3032. L’étiquette 0 est l’étiquette nulle explicite IPv4. L’étiquette 1 est l’équivalent MPLS de l’étiquette d’alerte de routeur IP, et l’étiquette 2 est l’étiquette NULL explicite IPv6.

Les cinq étiquettes restantes de la Destination colonne sont des étiquettes non réservées que le routeur utilise pour transférer le trafic, et la dernière colonne Netifindique les interfaces utilisées pour envoyer le trafic étiqueté. Pour les étiquettes non réservées, la deuxième Type colonne indique l’opération effectuée sur les paquets correspondants. Dans cet exemple, tous les paquets non réservés sont remplacés par des étiquettes de paquets sortants. Par exemple, les paquets avec l’étiquette 100112 voient leur étiquette permutée avant d’être poussés 100032 hors de l’interface so-0/0/1.0.

Vérifier le fonctionnement de l’équilibrage de charge de bande passante inégale

But

Lorsqu’un routeur effectue un équilibrage de charge à coût inégal entre les chemins LSP, la commande affiche un champ d’équilibre show route detail associé à chaque prochain saut utilisé.

Action

Pour vérifier qu’un LSP RSVP est inégalement équilibré en charge, utilisez les commandes suivantes en mode opérationnel de l’interface de ligne de commande Junos OS :

Exemple de sortie

nom_commande

Sens

L’exemple de sortie du routeur entrant R1 montre que le trafic est distribué en fonction de la configuration de bande passante LSP, comme indiqué par le Balance: xx% champ. Par exemple, lsp1 10 Mbits/s de bande passante sont configurés, comme indiqué dans le Balance: 10% champ.

Utiliser la commande traceroute pour vérifier les étiquettes MPLS

But

Vous pouvez utiliser la traceroute commande pour vérifier que les paquets sont envoyés via le LSP.

Action

Pour vérifier les étiquettes MPLS, entrez la commande suivante en mode opérationnel de l’interface de ligne de commande Junos OS, où host-name est l’adresse IP ou le nom de l’hôte distant :

Sortie de l’échantillon 1

nom_commande

Sortie de l’échantillon 2

nom_commande

Sens

L’exemple de sortie 1 montre que des étiquettes MPLS sont utilisées pour transférer des paquets à travers le réseau. La sortie comprend une valeur d’étiquette (MPLS Label=100048), la valeur de durée de vie (TTL=1) et la valeur du bit de pile (S=1).

Ce MPLS Label champ est utilisé pour identifier le paquet d’un LSP particulier. Il s’agit d’un champ de 20 bits, avec une valeur maximale de (2^^20-1), soit environ 1 000 000.

La valeur TTL contient une limite sur le nombre de sauts que ce paquet MPLS peut parcourir à travers le réseau (1). Il est décrémenté à chaque saut, et si la valeur TTL tombe en dessous de un, le paquet est rejeté.

La valeur du bit de pile inférieure (S=1) indique qu’il s’agit de la dernière étiquette de la pile et qu’une étiquette est associée à ce paquet MPLS. L’implémentation MPLS dans Junos OS prend en charge une profondeur d’empilage de 3 sur les routeurs de la série M et jusqu’à 5 sur les plates-formes de la série T. Pour plus d’informations sur l’empilage d’étiquettes MPLS, reportez-vous à la RFC 3032, Codage d’empilement d’étiquettes MPLS.

Les étiquettes MPLS apparaissent dans l’exemple de sortie 1, car la traceroute commande est émise vers une destination BGP où le tronçon BGP suivant pour cette route est l’adresse de sortie LSP. Le comportement par défaut de Junos OS utilise des LSP pour le trafic BGP lorsque le saut suivant BGP est égal à l’adresse de sortie LSP.

L’exemple de sortie 2 montre que les étiquettes MPLS n’apparaissent pas dans la sortie de la traceroute commande. Si le tronçon suivant BGP n’est pas égal à l’adresse de sortie du LSP ou si la destination est une route IGP, le trafic BGP n’utilise pas le LSP. Au lieu d’utiliser le LSP, le trafic BGP utilise l’IGP (IS-IS, dans ce cas) pour atteindre l’adresse de sortie (R6).

Dépannage des tunnels GMPLS et GRE

Problème

Description

Le canal de contrôle logique pour GMPLS doit être une liaison point à point et doit avoir une certaine forme d’accessibilité IP. Sur les interfaces de diffusion ou lorsqu’il existe plusieurs sauts entre les homologues du canal de contrôle, utilisez un tunnel GRE pour le canal de contrôle. Pour plus d’informations sur les tunnels GMPLS et GRE, consultez le Guide de configuration des applications MPLS Junos et le Guide de l’utilisateur Junos.

Un PIC de tunnel n’est pas nécessaire pour configurer un tunnel GRE pour le canal de contrôle GMPLS. Utilisez plutôt l’interface logicielle gre plutôt que l’interface matérielle gr-fpc/pic/port .

ATTENTION :

En raison des restrictions de l’interface logicielle gre , le canal de contrôle GMPLS est la seule utilisation prise en charge de l’interface logicielle gre . Toute autre utilisation n’est expressément pas prise en charge et peut entraîner une défaillance de l’application.

L’exemple suivant montre une configuration d’interface de base gre . Dans ce cas, la source du tunnel est l’adresse de bouclage du routeur local et l’adresse de destination est la destination de bouclage du routeur distant. Le trafic qui a un saut suivant de la destination du tunnel utilisera le tunnel. Le tunnel n’est pas automatiquement utilisé par l’ensemble du trafic passant par l’interface. Seul le trafic utilisant la destination du tunnel comme tronçon suivant utilise le tunnel.

Exemple de sortie

Exemple de sortie

L’exemple de sortie suivant pour la commande show interfaces montre le type d’encapsulation et l’en-tête, la vitesse maximale, les paquets via l’interface logique, la destination et l’adresse logique.

Vous devez configurer un LSP GMPLS à l’aide d’un tunnel GRE :

  • Le canal de données doit commencer et se terminer sur le même type d’interface.

  • Le canal de contrôle peut être un tunnel GRE qui commence et se termine sur le même type d’interface ou sur un type d’interface différent.

  • Le tunnel GRE doit être configuré indirectement avec l’instruction peer-interface peer-name au niveau de la [edit protocol ospf] hiérarchie.

  • L’interface GRE doit être désactivée au niveau de la [edit protocols ospf] hiérarchie et [edit protocols rsvp] .

  • Les canaux de données et de contrôle doivent être définis correctement dans la configuration LMP.

  • Il est facultatif de désactiver le CSPF (Constrained Shortest Path First) avec l’instruction no-cspf .

Ce cas se concentre sur la configuration incorrecte des points de terminaison du tunnel GRE. Cependant, vous pouvez utiliser un processus et des commandes similaires pour diagnostiquer d’autres problèmes de tunnel GRE. Figure 13 illustre une topologie de réseau avec MPLS tunnelisé via une interface GRE.

Figure 13 : Topologie du réseau GMPLSTopologie du réseau GMPLS

La topologie de réseau MPLS illustrée Figure 13 montre les routeurs Juniper Networks configurés avec un tunnel GRE composé des composants suivants :

  • Chemin LSP GMPLS strict du routeur entrant au routeur de sortie.

  • Sur le routeur entrant, CSPF désactivé avec l’instruction no-cspf au niveau de la hiérarchie [edit protocol mpls label-switched-path lsp-name].

  • Liens d’ingénierie du trafic et canaux de contrôle dans l’instruction peer au niveau de la hiérarchie [edit protocols link-management] sur tous les routeurs.

  • OSPF et l'ingénierie de trafic OSPF sont configurés sur tous les routeurs.

  • Une référence à l’dans peer-interface OSPF et RSVP sur tous les routeurs.

  • Problème de commutation entre R2 et R3.

Symptôme

Le LSP du réseau illustré dans Figure 13 est en panne, comme l’indique la sortie des show mpls lsp commandes et show rsvp session , qui affichent des informations très similaires. La show mpls lsp commande affiche tous les LSP configurés sur le routeur, ainsi que tous les LSP de transit et de sortie. La show rsvp session commande affiche des informations récapitulatives sur les sessions RSVP. Vous pouvez utiliser l’une ou l’autre commande pour vérifier l’état du LSP. Dans ce cas, LSP gmpls-r1-to-r3 est en panne (Dn).

Exemple de sortie

Cause

La cause du problème avec le LSP GMPLS est la configuration de différents types d’interfaces aux deux extrémités du canal de données GMPLS.

Commandes de dépannage

Junos OS inclut des commandes utiles pour résoudre un problème. Cette rubrique fournit une brève description de chaque commande, suivie d’un exemple de sortie et d’une discussion de la sortie en relation avec le problème.

Vous pouvez utiliser les commandes suivantes pour résoudre un problème GMPLS :

Exemple de sortie

Utilisez la commande show mpls lsp extensive sur le routeur de transit R1 pour afficher des informations détaillées sur tous les LSP en transit, en cours de terminaison et configurés sur le routeur.

Sens

L’exemple de sortie de la show mpls lsp extensive commande affiche un message d’erreur (MPLS label allocation failure) dans la section log de la sortie. Cet événement LSP indique que le protocole MPLS ou l’instruction n’ont family mpls pas été configurés correctement. Lorsque l’événement LSP est précédé d’une adresse IP, il s’agit généralement du routeur présentant l’erreur de configuration MPLS. Dans ce cas, il semble que le routeur avec l’adresse lo0 (R3) ait une erreur de 192.168.4.1 configuration MPLS.

Exemple de sortie

Utilisez la commande show rsvp session detail pour afficher des informations détaillées sur les sessions RSVP.

Sens

L’exemple de sortie de la show rsvp session detail commande montre que LSP gmpls-r1-to-r3 est en panne (LSPstate: Dn). L’enregistrement de l’itinéraire est incomplet, ce qui indique un problème avec l’itinéraire 100.100.100.100 93.93.93.93explicite. L’adresse 100.100.100.100 est le canal de données sur R2 so-0/0/0, et l’adresse 93.93.93.93 est le canal de données sur R3.

Exemple de sortie

Utilisez la commande show link-management peer pour afficher les informations sur les liaisons homologues MPLS.

Sens

L’exemple de sortie de tous les routeurs de l’exemple de réseau pour Figure 13 la show link-management peer commande montre que tous les canaux de contrôle sont actifs et actifs. Une analyse détaillée de la sortie montre les informations suivantes :

  • Nom de l’homologue, tester2 ou tester3, qui est le même sur les routeurs voisins pour faciliter le dépannage.

  • Identificateur interne pour l’homologue, 48428 pour tester2 et 48429 pour tester3. L’identificateur interne est une plage de valeurs comprise entre 0 et 64 000.

  • L’état de l’homologue, qui peut être vers le haut ou vers le bas. Dans ce cas, tous les pairs sont en place.

  • L’adresse vers laquelle un canal de contrôle est établi, par exemple, 10.35.1.5.

  • L’état du canal de contrôle, qui peut être actif, descendant ou actif.

  • Les liens d’ingénierie du trafic qui sont gérés par leur homologue, indiquant que le canal gre.0 de contrôle est géré par tester3.

Exemple de sortie

Utilisez la commande show link-management te-link pour afficher les ressources utilisées pour configurer les chemins de transfert MPLS (Multiprotocol Label Switching).

Sens

L’exemple de sortie de la show link-management te-link commande émise sur les trois routeurs du réseau en Figure 13 montre les ressources allouées aux liaisons te-tester2 d’ingénierie du trafic et te-tester3. Les ressources sont les interfaces so-0/0/0 SONET et so-0/0/1. On R1 et R2, tles interfaces SONET sont utilisées pour le LSP gmpls-r1-to-r3, comme indiqué par Yes dans le Used champ.Cependant, l’interface so-0/0/1 SONET activée R3 est désactivée (Dn) et n’est pas utilisée pour le LSP (Used No). Une enquête plus approfondie est nécessaire pour découvrir pourquoi l’interface SONET activée est en R3 panne.

Exemple de sortie

Utilisez la commande show log filename pour afficher le contenu du fichier journal spécifié. Dans ce cas, le fichier journal rsvp.log est configuré au niveau de la hiérarchie [edit protocols rsvp traceoptions]. Lorsque le fichier journal est configuré, vous devez exécuter la commande monitor start filename pour commencer à consigner les messages dans le fichier.

REMARQUE :

L’option find Error entrée après le tube ( | ) recherche dans la sortie une instance du terme Error.

Exemple de sortie

Sens

L’exemple de sortie du routeur de sortie R3 pour la show log rsvp.log commande est un extrait extrait du fichier journal. L’extrait de code montre une demande de ressource LMP (Link Management Protocol) pour le LSP gmpls-r1-to-r3. La demande présente des problèmes avec le type d’encodage (SDH/SONET), ce qui indique une erreur possible avec la connexion R2 de l’interface SONET et R3. Un examen plus approfondi de la configuration du LMP R2R3 est nécessaire.

Exemple de sortie

Utilisez la commande show configuration statement-path pour afficher une hiérarchie de configuration spécifique ; dans ce cas, link-management.

Sens

L’exemple de sortie du routeur R2 de transit et du routeur entrant R3 pour la show configuration protocols link-management commande montre que le type d’interface sur les deux routeurs est différent. La ressource allouée au te-tester3 routeur R2 de transit est une interface SONET, tandis que la ressource allouée au te-tester3 routeur de sortie R3 est une interface ATM. Le type d’interface à chaque extrémité des canaux de données ou de contrôle doit être du même type. Dans ce cas, les deux extrémités doivent être SONET ou ATM.

Solution

Solution

La solution au problème des différents types d’interface ou d’encapsulation à chaque extrémité du LSP GMPLS est de s’assurer que le type d’interface est le même aux deux extrémités. Dans ce cas, l’interface ATM a été supprimée de la configuration de gestion des liens le R3, et une interface SONET a été configurée à la place.

Les commandes suivantes illustrent la configuration et les commandes correctes pour vérifier que le LSP GMPLS est opérationnel et utilise le canal de données :

Exemple de sortie

Sens

L’exemple de sortie pour les show protocols link-managementcommandes , show mpls lsp, et show link-management te-link du routeur entrant R3 montre que le problème est résolu. LMP est correctement configuré et le LSP gmpls-r1-to-r3 est opérationnel et utilise le canal so-0/0/1de données .

Conclusion

En conclusion, les deux extrémités d’un canal de données GMPLS doivent avoir le même type d’encapsulation ou d’interface. Ce cas illustre la configuration correcte du canal de données. Les principes sont les mêmes pour le canal de régulation.

Configurations des routeurs

Sortie qui affiche les configurations du routeur entrant dans le réseau. L’option no-more entrée après le tube ( | ) empêche la pagination de la sortie si la sortie est plus longue que la longueur de l’écran du terminal.

Exemple de sortie

L’exemple de sortie suivant concerne le routeur entrant R1 :

Exemple de sortie

L’exemple de sortie suivant est pour le routeur de transit R2 :

Exemple de sortie

L’exemple de sortie suivant concerne le routeur de sortie R3 :

Détermination du statut de LSP

Affichez des informations détaillées sur les objets RSVP (Resource Reservation Protocol) et l’historique du chemin de commutation d’étiquettes (LSP) pour identifier un problème avec le LSP.

Figure 14 illustre la topologie de réseau utilisée dans cette rubrique.

Figure 14 : Topologie de réseau MPLSTopologie de réseau MPLS

Pour déterminer l’état LSP, procédez comme suit :

Vérifier l’état du LSP

But

Affichez l’état de la fenêtre de commutation d’étiquettes (LSP).

Action

Pour déterminer l’état du LSP, sur la routeur entrant, entrez la commande suivante Junos OS mode opérationnel de l’interface de ligne de commande (CLI) :

Exemple de sortie
nom_commande

Sens

L’exemple de sortie provient du routeur entrant (R1) et affiche les informations LSP d’entrée, de sortie et de transit. Les informations d’entrée concernent les sessions qui proviennent de ce routeur, les informations de sortie concernent les sessions qui se terminent sur ce routeur et les informations de transit concernent les sessions qui transitent par ce routeur.

Il existe une route d’entrée de R1 (10.0.0.1) à R6 (10.0.0.6). Cette route est actuellement active et est une route active installée dans la table de routage (Rt). Le LSP R1-to-R6 est le chemin principal (P) par opposition au chemin secondaire, et est indiqué par un astérisque (*). La route vers ne contient pas de chemin nommé R6 (ActivePath).

Il existe un LSP de sortie de R6 à R1. Le State est actif, sans routes installées dans la table de routage. Le style de réservation RSVP (Style) se compose de deux parties. Le premier est le nombre de réservations actives (1). Le second est le style de réservation, qui est FF (filtre fixe). Le style de réservation peut être FF, SE (partagé explicite) ou WF (filtre générique). Il y a trois étiquettes entrantes (Labelin) et aucune étiquette sortante (Labelout) pour ce LSP.

Il n’y a pas de LSP de transit.

Pour plus d’informations sur la vérification de l’état LSP, consultez Liste de contrôle pour l’utilisation du modèle de dépannage MPLS en couches.

Affichage de l’état complet du LSP

But

Affichez des informations détaillées sur les LSP, y compris tout l’historique des états passés et les raisons pour lesquelles un LSP a pu échouer.

Action

Pour afficher des informations détaillées sur les LSP, sur le routeur entrant, entrez la commande suivante en mode opérationnel CLI Junos OS :

Exemple de sortie
nom_commande

Sens

L’exemple de sortie provient du routeur entrant (R1) et affiche en détail les informations LSP d’entrée, de sortie et de transit, y compris tout l’historique des états passés et les raisons de la défaillance d’un LSP. Les informations d’entrée concernent les sessions qui proviennent de ce routeur, les informations de sortie sont celles des sessions qui se terminent sur ce routeur et les informations de transit concernent les sessions qui transitent par ce routeur.

Il existe une route d’entrée de R1 (10.0.0.1) à R6 (10.0.0.6). Cette route est actuellement en hausse (State), avec une route utilisant activement le LSP, R1-to-R6. Le chemin actif LSP est le chemin principal. Même si le LSP ne contient pas de primary mot-clé or secondary , le routeur le traite toujours comme un LSP principal, ce qui indique qu’en cas de défaillance du LSP, le routeur tentera de signaler les LSP inactifs à des intervalles de 30 secondes, par défaut.

L’équilibrage de charge est Random, qui est la valeur par défaut, ce qui indique que lors de la sélection du chemin physique pour un LSP, le routeur sélectionne de manière aléatoire parmi les chemins à coût égal qui ont un nombre égal de sauts. Les autres options que vous pouvez configurer sont Least-fill et Most-fill. Least-fill Place le LSP sur le lien le moins utilisé des chemins à coût égal avec un nombre de sauts égal. Most-fill Place le LSP sur le lien le plus utilisé des chemins à coût égal partageant un nombre de sauts égal. L’utilisation est basée sur le pourcentage de bande passante disponible.

Le Encoding type champ affiche les paramètres de signalisation MPLS généralisés (GMPLS) (Packet), indiquant IPv4. Le Switching type est Packet, et l’identificateur de charge utile généralisé (GPID) est IPv4.

Le chemin principal est le chemin actif, indiqué par un astérisque (*). L’état du LSP est Up.

L’objet de route explicite (ERO) inclut le coût20 CSPF (Constrained Shortest Path First) () pour le chemin physique suivi par le LSP. La présence de la métrique CSPF indique qu’il s’agit d’un LSP CSPF. L’absence de la métrique CSPF indique qu’il n’y a pas de LSP CSPF.

Le champ 10.1.13.2 S indique l’ERO réel. Les messages de signalisation RSVP sont passés à 10.1.13.2 strict (en tant que saut suivant) et se sont terminés à 10.1.36.2 strictly. Toutes les adresses ERO sont des sauts stricts lorsque le LSP est un LSP CSPF. Les sauts lâches ne peuvent s’afficher que dans un LSP no-CSPF.

L’objet Record Route (RRO) reçu possède les indicateurs de protection suivants :

  • 0x01—Protection locale disponible. Le lien en aval de ce noeud est protégé par un mécanisme de réparation local. Cet indicateur ne peut être défini que si l’indicateur de protection locale a été défini dans l’objet SESSION_ATTRIBUTE du message de chemin correspondant.

  • 0x02—Protection locale en cours d’utilisation. Un mécanisme de réparation local est utilisé pour maintenir ce tunnel (généralement en raison d’une panne de la liaison sur laquelle il a été acheminé précédemment).

  • 0x04— Protection de la bande passante. Le routeur en aval dispose d’un chemin de secours offrant la même garantie de bande passante que le LSP protégé pour la section protégée.

  • 0x08—Protection des nœuds. Le routeur en aval dispose d’un chemin de secours qui assure une protection contre les défaillances de liaison et de nœud sur la section de chemin correspondante. Si le routeur en aval ne peut configurer qu’un chemin de sauvegarde de protection de liaison, le bit « Protection locale disponible » est positionné mais le bit « Protection du nœud » est effacé.

  • 0x10—Préemption en cours. Le nœud de préemption définit cet indicateur si une préemption en attente est en cours pour le LSP d’ingénierie de trafic. Cela indique au routeur de périphérie d’étiquette d’entrée (LER) de ce LSP qu’il doit être réacheminé.

Pour plus d’informations sur les indicateurs de protection, reportez-vous au Guide de référence des commandes Junos Routing Protocols and Policies.

Le champ 10.1.13.2.10.1.36.2 est l’itinéraire réel de l’enregistrement reçu (RRO). Notez que les adresses du RRO champ correspondent à celles du ERO champ. C’est le cas normal pour les LSP de la CSPF. Si les adresses RRO et ERO ne correspondent pas à celles d’un LSP CSPF, le fournisseur de services linguistiques doit être réacheminé ou faire un détour.

Les lignes numérotées de 91 à 42 contiennent les 49 entrées les plus récentes du journal d’historique. Chaque ligne est horodatée. Les entrées les plus récentes ont le numéro d’historique de journal le plus élevé et se trouvent en haut du journal, ce qui indique que la ligne 91 est l’entrée de journal d’historique la plus récente. Lorsque vous lisez le journal, commencez par l’entrée la plus ancienne (42) jusqu’à la plus récente (91).

Le journal d’historique a été démarré le 10 juillet et affiche la séquence d’activités suivante : un LSP a été sélectionné comme actif, s’est avéré être inactif, l’attribution d’étiquettes MPLS a échoué plusieurs fois, a été supprimée plusieurs fois, a été préemptée en raison d’un ResvTear, a été désélectionnée comme active et a été effacée. En fin de compte, le routeur a calculé un ERO CSPF, a signalé l’appel, le LSP a trouvé le RRO répertorié (ligne 90) et a été répertorié comme actif.

Pour plus d’informations sur les messages d’erreur, reportez-vous à la référence du journal du Guide d’exploitation réseau MPLS Junos.

Le nombre total de LSP d’entrée affichés est 1, avec 1 up et 0 down. Le nombre dans le Up champ plus le nombre dans le Down champ doit être égal au total.

Il existe une session LSP de sortie de R6 à R1. Le State est actif, sans routes installées dans la table de routage. Le style de réservation RSVP (Style) se compose de deux parties. Le premier est le nombre de réservations actives (1). Le second est le style de réservation, qui est FF (filtre fixe). Le style de réservation peut être FF, SE (partagé explicite) ou WF (filtre générique). Il y a trois étiquettes entrantes (Labelin) et aucune étiquette sortante (Labelout) pour ce LSP.

Il n’y a pas de LSP de transit.

Pour plus d’informations sur la vérification de l’état LSP, consultez Liste de contrôle pour l’utilisation du modèle de dépannage MPLS en couches.

Vérification de l’envoi et de la réception des messages du chemin RSVP

But

La présence ou l’absence de divers messages RSVP peut aider à déterminer s’il existe un problème avec la commutation d’étiquette multiprotocole (MPLS) dans votre réseau. Par exemple, si des messages de chemin d’accès apparaissent dans la sortie sans messages Resv, cela peut indiquer que les chemins de commutation d’étiquettes (LSP) ne sont pas créés.

Action

Pour vérifier que les messages RSVP Path sont envoyés et reçus, entrez la commande suivante en mode opérationnel de l’interface de ligne de commande (CLI) Junos OS :

Exemple de sortie

nom_commande

Sens

L’exemple de sortie montre les messages RSVP envoyés et reçus. Le nombre total de messages RSVP Path est de 11 4532 envoyés et 80 185 reçus. Au cours des 5 dernières secondes, aucun message n’a été envoyé ou reçu.

Au total, 5 PathErr messages ont été envoyés et 10 reçus. Lorsque des erreurs de chemin se produisent (généralement en raison de problèmes de paramètres dans un message de chemin), le routeur envoie un message PathErr unicast à l’expéditeur qui a émis le message de chemin. Dans ce cas, R1 envoyez au moins 10 messages de chemin d’accès avec une erreur, comme indiqué par les 10 messages PathErr reçus R1 . Le routeur en aval a envoyé R1 cinq messages de chemin avec une erreur, comme indiqué par les cinq messages PathErr qui R1 ont été envoyés. Les messages PathErr sont transmis dans la direction opposée aux messages de chemin.

Au total, 12 PathTear messages ont été envoyés et 6 reçus, aucun au cours des 5 dernières secondes. Contrairement aux messages PathErr, les messages PathTear voyagent dans la même direction que les messages de chemin. Étant donné que les messages de chemin sont à la fois envoyés et reçus, les messages PathTear sont également envoyés et reçus. Toutefois, si seuls les messages de chemin d’accès sont envoyés, seuls les messages PathTear envoyés apparaissent dans la sortie.

Au total, 80 515 messages de réservation (Resv) avec le filtre fixe (FF) style de réservation ont été envoyés et 111 476 reçus, dont aucun au cours des 5 dernières secondes. Un FF style de réservation indique qu’au sein de chaque session, chaque destinataire établit sa propre réservation avec chaque expéditeur en amont, et que tous les expéditeurs sélectionnés sont répertoriés. Aucun message pour le filtre générique (WF) ou les styles de réservation explicites partagés (SE) n’est envoyé ou reçu. Pour plus d’informations sur les styles de réservation RSVP, reportez-vous au Guide de configuration des applications MPLS Junos.

Les autres types de messages de réponse ne sont ni envoyés ni reçus. Pour plus d’informations sur les types de messages ResvErr, ResvTear et Resvconf, reportez-vous au Guide de configuration des applications MPLS Junos.

Les messages d’accusé de réception et d’actualisation récapitulative (SRefresh) n’apparaissent pas dans la sortie. Les messages d’actualisation Ack et Summary sont définis dans la RFC 2961 et font partie des extensions RSVP. Les messages d’accusé de réception sont utilisés pour réduire la quantité de trafic de contrôle RSVP dans le réseau.

Au total, 915 851 messages de bonjour ont été envoyés et 915 881 ont été reçus, aucun n’ayant été transmis ou reçu au cours des 5 dernières secondes. L’intervalle de salutation RSVP est de 9 secondes. Si plusieurs messages de bonjour sont envoyés ou reçus au cours des 5 dernières secondes, cela implique que plusieurs interfaces prennent en charge RSVP.

EndtoEnd Les messages RSVP sont des messages RSVP hérités qui ne sont pas utilisés pour l’ingénierie du trafic RSVP. Ces compteurs ne s’incrémentent que lorsque RSVP transfère les anciens messages RSVP émis par un client de réseau privé virtuel (VPN) pour qu’ils transitent sur la dorsale vers le ou les autres sites du VPN. Ils sont appelés messages de bout en bout parce qu’ils sont destinés à l’autre côté du réseau et n’ont de signification qu’aux deux extrémités du réseau du fournisseur.

La Errors section de la sortie affiche des statistiques sur les paquets RSVP avec des erreurs. Au total, 15 PathErr to client paquets ont été envoyés au moteur de routage. Le total combine les paquets envoyés et reçus PathErr .