LDP Configuration

Configuration du timer LDP pour les liaisons Hello Messages

Pour modifier la fréquence à laquelle LDP envoie des liaisons bonjour messages, spécifiez un nouveau lien hello message intervalle pour le timer LDP à l’aide de l’instruction hello-interval :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

Configuration du timer LDP pour les messages bonjour ciblés

Pour modifier la fréquence à laquelle LDP envoie des messages de bonjour ciblés, spécifiez un nouvel intervalle de message bonjour ciblé pour le timer LDP en configurant l’instruction hello-interval en tant qu’option pour l’instruction targeted-hello :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure ces déclarations, consultez les sections de synthèse de ces déclarations.

Configuration du temps d’attente LDP pour les messages De liaison Hello

Pour modifier la durée d’attente d’un nœud LDP avant de déclarer le voisin vers le bas, spécifiez une nouvelle heure en quelques secondes à l’aide de l’énoncé hold-time :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

Configuration du temps d’attente LDP pour les messages bonjour ciblés

Pour modifier la durée d’attente d’un nœud LDP avant de déclarer le voisin vers le bas, spécifiez une nouvelle heure en quelques secondes en utilisant l’instruction hold-time comme option pour l’instruction targeted-hello :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure ces déclarations, consultez les sections de synthèse de ces déclarations.

Activation d’un redémarrage progressif

Pour activer le redémarrage progressif LDP, vous devez également activer le redémarrage progressif sur le routeur. Pour permettre un redémarrage progressif, incluez l’énoncé graceful-restart :

Vous pouvez inclure cette déclaration aux niveaux hiérarchiques suivants :

• [edit routing-options]

• [edit logical-systems logical-system-name routing-options]

REMARQUE :

Les routeurs ACX Series ne prennent pas en charge le niveau hiérarchique [edit logical-systems logical-system-name routing-options].

L’instruction graceful-restart permet un redémarrage progressif pour tous les protocoles prenant en charge cette fonctionnalité sur le routeur. Pour plus d’informations sur le redémarrage progressif, consultez la bibliothèque de protocoles de routage Junos OS pour les équipements de routage.

Par défaut, le redémarrage progressif LDP est activé lorsque vous activez le redémarrage progressif au niveau du protocole LDP et sur toutes les instances de routage. Toutefois, vous pouvez désactiver à la fois le mode d’aide au redémarrage progressif LDP et le mode d’aide au redémarrage progressif LDP.

Désactiver le mode LDP Graceful Restart ou Helper

Pour désactiver le redémarrage et la récupération progressifs LDP, incluez l’énoncé disable :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

Vous pouvez désactiver le mode d’assistance au niveau des protocoles LDP uniquement. Vous ne pouvez pas désactiver le mode d’assistance pour une instance de routage spécifique. Pour désactiver le mode d’assistance LDP, incluez l’énoncé helper-disable :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

Les configurations de redémarrage progressif LDP suivantes sont possibles :

• Le redémarrage progressif LDP et le mode d’assistance sont tous deux activés.

• Le redémarrage progressif LDP est désactivé, mais le mode d’assistance est activé. Un routeur configuré de cette manière ne peut pas redémarrer gracieusement, mais peut aider un voisin qui redémarre.

• Le redémarrage progressif LDP et le mode d’assistance sont tous deux désactivés. Le routeur n’utilise pas de redémarrage progressif LDP ou le type, la longueur et la valeur (TLV) envoyés dans le message d’initialisation. Le routeur se comporte comme un routeur qui ne peut pas prendre en charge le redémarrage progressif LDP.

Une erreur de configuration est émise si vous tentez d’activer le redémarrage progressif et de désactiver le mode d’assistance.

Configuration de l’heure de connexion

Après l’échec de la connexion LDP entre voisins, les voisins attendent un certain temps pour que le routeur qui redémarre gracieusement reprenne l’envoi de messages LDP. Après la période d’attente, la session LDP peut être rétablie. Vous pouvez configurer la période d’attente en quelques secondes. Cette valeur est incluse dans la tolérance de session TLV envoyée dans les messages d’initialisation LDP lorsque le redémarrage progressif LDP est activé.

Supposons que le routeur A et le routeur B soient voisins LDP. Le routeur A est le routeur de redémarrage. Le temps de reconnexion est le temps que le routeur A indique au routeur B d’attendre après que le routeur B détecte que le routeur A a redémarré.

Pour configurer le temps de reconnexion, incluez l’instruction reconnect-time :

Vous pouvez définir le temps de connexion à une valeur comprise entre 30 et 300 secondes. Par défaut, il est de 60 secondes.

Pour obtenir la liste des niveaux hiérarchiques sur lesquels vous pouvez configurer ces instructions, consultez les sections de synthèse de ces déclarations.

Configuration du temps de récupération et du temps de récupération maximal

Le temps de récupération est le temps qu’un routeur attend pour que le LDP redémarre correctement. La période de récupération commence lorsqu’un message d’initialisation est envoyé ou reçu. Cette période correspond généralement au temps qu’un routeur voisin conserve ses informations sur le routeur de redémarrage, ce qui lui permet de continuer à transférer le trafic.

Pour éviter qu’un routeur voisin ne soit affecté s’il reçoit une fausse valeur pour le temps de récupération du routeur de redémarrage, vous pouvez configurer le temps de récupération maximum sur le routeur voisin. Un routeur voisin maintient son état pendant la plus courte des deux fois. Par exemple, le routeur A effectue un redémarrage progressif LDP. Il a envoyé un temps de récupération de 900 secondes au routeur B voisin. Cependant, le temps de récupération maximal du routeur B est configuré à 400 secondes. Le routeur B n’attend que 400 secondes avant de purger ses informations LDP du routeur A.

Pour configurer le temps de récupération, incluez l’instruction recovery-time et l’instruction maximum-neighbor-recovery-time :

Pour obtenir la liste des niveaux hiérarchiques sur lesquels vous pouvez configurer ces instructions, consultez les sections de synthèse de ces déclarations.

Exemples: Filtrage des liaisons d’étiquettes LDP entrantes

N’acceptez que /32 préfixes de tous les voisins :

Accepter 131.108/16 ou plus à partir de l’ID 10.10.255.2 de routeur et accepter tous les préfixes de tous les autres voisins :

Exemples: Filtrage des liaisons d’étiquettes LDP sortantes

Bloc transmission de la route pour 10.10.255.6/32 n’importe quel voisin :

Envoyez uniquement 131.108/16 ou plus à l’ID 10.10.255.2du routeur , et envoyez tous les préfixes à tous les autres routeurs :

Avantages du contrôle de l’adresse de transport utilisée pour les sessions LDP ciblées

La configuration de l’adresse de transport pour l’établissement de sessions LDP ciblées présente les avantages suivants :

• Flexible interface configurations— Permet de configurer plusieurs adresses IP pour une interface de bouclage sans interrompre la création d’une session LDP entre les voisins LDP ciblés.

• Ease of operation— L’adresse de transport configurée au niveau de l’interface vous permet d’utiliser plusieurs protocoles dans la dorsale IGP pour LDP. Cela permet des opérations fluides et faciles.

Présentation de l’adresse de transport Targeted-LDP

Avant la version 19.1R1 de Junos OS, LDP ne supportait que l’ID de routeur ou l’adresse d’interface en tant qu’adresse de transport sur n’importe quelle interface LDP. Les adjacencies formées sur cette interface utilisent l’une des adresses IP attribuées à l’interface ou à l’ID de routeur. En cas d’adjacence ciblée, l’interface est l’interface de bouclage. Lorsque plusieurs adresses de bouclage ont été configurées sur l’équipement, l’adresse de transport n’a pas pu être dérivée pour l’interface et, par conséquent, la session LDP n’a pas pu être établie.

À partir de la version 19.1R1 de Junos OS, en plus des adresses IP par défaut utilisées pour l’adresse de transport des sessions LDP ciblées, vous pouvez configurer n’importe quelle autre adresse IP en tant qu’adresse de transport sous les session, session-groupet interface les déclarations de configuration. La configuration de l’adresse de transport s’applique uniquement aux voisins configurés, y compris les circuits de couche 2, les adjacencies MPLS et VPLS. Cette configuration ne s’applique pas aux adjacencies découvertes (ciblées ou non).

Préférences d’adresse de transport

Vous pouvez configurer l’adresse de transport pour les sessions LDP ciblées au niveau de la session, du groupe de session et de l’interface.

Une fois l’adresse de transport configurée, la session LDP ciblée est établie en fonction de la préférence d’adresse de transport de LDP.

L’ordre de préférence de l’adresse de transport pour le voisin cible (configuré via circuit de couche 2, MPLS, VPLS et configuration LDP) est le suivant :

1. Sous [edit protocols ldp session] hiérarchie.

2. Sous [edit protocols ldp session-group] hiérarchie.

3. Sous [edit protocols ldp interfcae lo0] hiérarchie.

4. Sous [edit protocols ldp] hiérarchie.

5. Adresse par défaut.

L’ordre de préférence de l’adresse de transport pour les voisins découverts est le suivant :

1. Sous [edit protocols ldp interfcae] hiérarchie.

2. Sous [edit protocols ldp] hiérarchie.

3. Adresse par défaut.

L’ordre de préférence de l’adresse de transport pour les voisins ciblés automatiquement où LDP est configuré pour accepter les paquets bonjour est le suivant :

1. Sous [edit protocols ldp interfcae lo0] hiérarchie.

2. Sous [edit protocols ldp] hiérarchie.

3. Adresse par défaut.

Dépannage de la configuration des adresses de transport

Vous pouvez utiliser les sorties de commande show suivantes pour résoudre les problèmes liés aux sessions LDP ciblées :

• show ldp session

• show ldp neighbor

  Le detail niveau de sortie de la show ldp neighbor commande affiche l’adresse de transport envoyée dans les messages bonjour au voisin ciblé. Si cette adresse n’est pas accessible depuis le voisin, la session LDP n’est pas disponible.

• show configuration protocols ldp

Vous pouvez également activer les options de traçage LDP pour un dépannage plus poussé.

• Si la configuration passe d’une adresse de transport non valide (non accessible) à une adresse de transport valide, les traces suivantes peuvent être observées :

• Si la configuration est remplacée par une adresse de transport valide par une adresse de transport non valide (non accessible), les traces suivantes peuvent être observées :

En cas de configuration défaillante, effectuez les tâches de dépannage suivantes :

• Consultez le fichier address family. L’adresse de transport configurée dans l’instruction session doit appartenir à la même famille d’adresses que le voisin ou la session.

• L’adresse configurée en tant qu’adresse de transport sous une neighbor ou session instruction doit être locale au routeur pour que les messages de bonjour ciblés commencent. Vous pouvez vérifier si l’adresse est configurée. Si l’adresse n’est configurée sous aucune interface, la configuration est rejetée.

Exemple : Configuration des préfixes annoncés dans LDP

Annoncez toutes les routes connectées dans LDP :

Présentation du MoFRR

Avec un reroutage rapide sur des flux unicast, un équipement de routage en amont pré-établit des chemins de commutation d’étiquettes (LSP) MPLS ou précompte un chemin de secours rapide de secours sans boucle IP (LFA) pour gérer la défaillance d’un segment du chemin en aval.

Dans le routage multicast, le côté récepteur est généralement à l’origine des graphiques de distribution du trafic. Contrairement au routage unicast, qui établit généralement le chemin de la source au récepteur. PIM (pour IP), multipoint LDP (pour MPLS) et RSVP-TE (pour MPLS) sont des protocoles capables d’établir des graphiques de distribution multicast. Parmi ces derniers, les récepteurs PIM et LDP multipoint initient la configuration du graphique de distribution, de sorte que MoFRR peut fonctionner avec ces deux protocoles multicast où ils sont pris en charge.

Dans un arbre multicast, si l’équipement détecte une défaillance d’un composant réseau, il faut un certain temps pour effectuer une réparation réactive, ce qui entraîne une perte de trafic importante tout en mettant en place un autre chemin. Le MoFRR réduit les pertes de trafic dans un arbre de distribution multicast en cas de défaillance d’un composant réseau. Avec le MoFRR, l’un des équipements de routage en aval configure un chemin alternatif vers la source pour recevoir un flux de secours en direct du même trafic multicast. Lorsqu’une défaillance survient le long du flux principal, l’équipement de routage MoFRR peut rapidement passer au flux de secours.

Une fois le MoFRR activé, pour chaque entrée (S,G), l’équipement utilise deux des interfaces en amont disponibles pour envoyer un message de jointure et recevoir du trafic multicast. Le protocole tente de sélectionner deux chemins disjoints si deux chemins de ce type sont disponibles. Si des chemins disjoints ne sont pas disponibles, le protocole sélectionne deux chemins non disjoints. Si deux chemins non disjoints ne sont pas disponibles, seul un chemin principal est sélectionné sans sauvegarde. Le MoFRR donne la priorité à la sauvegarde disjointe en faveur de l’équilibrage de charge des chemins disponibles.

Le MoFRR est pris en charge à la fois pour les familles de protocoles IPv4 et IPv6.

Figure 12 affiche deux chemins entre l’équipement de routage de récepteur multicast (également appelé équipement de périphérie du fournisseur sortant (PE) vers l’équipement de routage source multicast (également appelé équipement PE entrant).

Une fois le MoFRR activé, l’équipement de routage sortant (côté récepteur) configure deux arbres multicast, un chemin principal et un chemin de secours, vers la source multicast pour chaque (S, G). En d’autres termes, l’équipement de routage sortant propage les mêmes messages de jointure (S, G) vers deux voisins en amont différents, créant ainsi deux arbres multicast.

L’un des arbres multicast passe par le plan 1 et l’autre par le plan 2, comme illustré dans Figure 12. Pour chaque (S,G), l’équipement de routage sortant transfère le trafic reçu sur le chemin principal et abandonne le trafic reçu sur le chemin de secours.

Le MoFRR est pris en charge à la fois sur les chemins ECMP (Equal-Cost Multipath) et sur les chemins non-ECMP. L’équipement doit activer des routes alternatives (LFA) sans boucle unicast pour prendre en charge le MoFRR sur les chemins non-ECMP. Vous activez les routes LFA à l’aide de l’instruction link-protection dans la configuration IGP (Interior Gateway Protocol). Lorsque vous activez la protection des liaisons sur une interface OSPF ou IS-IS, l’équipement crée un chemin LFA de secours vers le saut suivant principal pour toutes les routes de destination qui traversent l’interface protégée.

Junos OS implémente le MoFRR dans le réseau IP moFRR et au niveau de l’équipement de routage de périphérie d’étiquettes (LER) MPLS pour moFRR LDP multipoint.

Le MoFRR LDP multipoint est utilisé sur l’équipement sortant d’un réseau MPLS, où les paquets sont transférés vers un réseau IP. Avec le MoFRR LDP multipoint, l’équipement établit deux chemins vers l’équipement de routage PE en amont pour recevoir deux flux de paquets MPLS au niveau du LER. L’équipement accepte l’un des flux (le principal), et l’autre (la sauvegarde) est abandonné au LER. Si le chemin principal échoue, l’équipement accepte le flux de secours à la place. La prise en charge de la signalisation inband est un pré-requis pour le MoFRR avec LDP multipoint (voir Comprendre la signalisation multipoint LDP inband pour les LSP point à multipoint).

Fonctionnalité PIM

Junos OS prend en charge MoFRR pour les liaisons SPT (Short-Path Tree) dans PIM source-specific multicast (SSM) et any-source multicast (ASM). Le MoFRR est pris en charge pour les gammes SSM et ASM. Pour activer MoFRR pour les jointure (*,G), incluez l’instruction mofrr-asm-starg de configuration dans la [edit routing-options multicast stream-protection] hiérarchie. Pour chaque groupe G, le MoFRR fonctionnera pour (S,G) ou (*,G), mais pas les deux. (S,G) prend toujours le pas sur (*,G).

Avec l’activation du MoFRR, un équipement de routage PIM propage des messages de jointure sur deux interfaces RPF (Reverse-Path Forwarding) en amont pour recevoir du trafic multicast sur les deux liaisons pour la même demande de jointure. Le MoFRR donne la préférence à deux chemins qui ne convergent pas vers le même équipement de routage immédiat en amont. PIM installe des routes multicast appropriées avec les sauts suivants RPF en amont avec deux interfaces (pour les chemins primaires et de secours).

En cas d’échec du chemin principal, le chemin de secours est mis à niveau vers le statut principal et l’équipement transfère le trafic en conséquence. S’il existe d’autres chemins disponibles, le MoFRR calcule un nouveau chemin de sauvegarde et met à jour ou installe le routage multicast approprié.

Vous pouvez activer le MoFRR avec l’équilibrage de charge pim de jointure (voir l’énoncé join-load-balance automatic ). Cependant, dans ce cas, la distribution des messages de jointure parmi les liens peut ne pas être égale. Lorsqu’une nouvelle liaison ECMP est ajoutée, les messages de jointure sur le chemin principal sont redistribués et les charges sont équilibrées. Les messages de jointure sur le chemin de sauvegarde peuvent toujours suivre le même chemin et ne peuvent pas être redistribués uniformément.

Vous activez le MoFRR à l’aide de l’énoncé stream-protection de configuration dans la [edit routing-options multicast] hiérarchie. Le MoFRR est géré par un ensemble de stratégies de filtrage.

Lorsqu’un équipement de routage PIM sortant reçoit un message de jointure ou un rapport IGMP, il vérifie une configuration MoFRR et procède comme suit :

• Si la configuration MoFRR n’est pas présente, le PIM envoie un message de jointure en amont à un voisin en amont (par exemple, le plan 2 in Figure 12).

• Si la configuration MoFRR est présente, l’équipement recherche une configuration de stratégie.

• Si une stratégie n’est pas présente, l’équipement vérifie les chemins primaires et de secours (interfaces en amont) et procède comme suit :

  • Si les chemins primaires et de secours ne sont pas disponibles, pim envoie un message de jointure en amont à un voisin en amont (par exemple, plan 2 in Figure 12).

  • Si des chemins primaires et de sauvegarde sont disponibles, le PIM envoie le message de jointure en amont à deux des voisins en amont disponibles. Junos OS configure des chemins multicast primaires et secondaires pour recevoir le trafic multicast (par exemple, le plan 1 en Figure 12).

• Si une politique est présente, l’équipement vérifie si la stratégie autorise le MoFRR pour cela (S,G), et procède comme suit :

  • Si cette vérification des stratégies échoue, le PIM envoie un message de jointure en amont à un voisin en amont (par exemple, le plan 2 in Figure 12).

  • Si cette vérification des stratégies est effectuée , l’équipement vérifie les chemins primaires et de secours (interfaces en amont).

    • Si les chemins primaires et de sauvegarde ne sont pas disponibles, PIM envoie un message de jointure en amont à un voisin en amont (par exemple, le plan 2 in Figure 12).

    • Si les chemins primaires et de sauvegarde sont disponibles, le PIM envoie le message de jointure en amont à deux des voisins en amont disponibles. L’équipement configure des chemins multicast primaires et secondaires pour recevoir le trafic multicast (par exemple, plan 1 in Figure 12).

Fonctionnalité LDP multipoint

Pour éviter la duplication du trafic MPLS, le LDP multipoint ne sélectionne généralement qu’un seul chemin en amont. (Voir la section 2.4.1.1. Détermination du « LSR en amont » dans la RFC 6388, extensions du protocole de distribution d’étiquettes pour les chemins de commutation d’étiquettes point à multipoint et multipoint à multipoint.)

Pour le LDP multipoint avec MoFRR, l’équipement LDP multipoint sélectionne deux pairs en amont distincts et envoie deux labels distincts, une à chaque homologue en amont. L’équipement utilise le même algorithme décrit dans la RFC 6388 pour sélectionner le chemin principal en amont. L’équipement utilise le même algorithme pour sélectionner le chemin en amont de secours, mais exclut le LSR principal en amont comme candidat. Les deux pairs en amont envoient deux flux de trafic MPLS vers l’équipement de routage sortant. L’équipement ne sélectionne qu’un seul des chemins voisins en amont comme chemin principal à partir duquel accepter le trafic MPLS. L’autre chemin devient le chemin de secours, et l’équipement abandonne ce trafic. Lorsque le chemin principal en amont échoue, l’équipement commence à accepter le trafic du chemin de sauvegarde. L’équipement LDP multipoint sélectionne les deux chemins en amont en fonction du saut suivant de l’équipement racine IGP (Interior Gateway Protocol).

Une classe d’équivalence de transfert (FEC) est un groupe de paquets IP qui sont transférés de la même manière, sur le même chemin et avec le même traitement de transfert. Normalement, le label qui est placé sur un paquet particulier représente le FEC auquel ce paquet est assigné. Dans le MoFRR, deux routes sont placées dans la table mpls.0 pour chaque FEC : une route pour le label principal et l’autre pour le label de secours.

S’il existe des liaisons parallèles vers le même équipement immédiat en amont, l’équipement considère les deux liaisons parallèles comme étant la principale. À tout moment, l’équipement en amont envoie du trafic sur une seule des multiples liaisons parallèles.

Un nœud bud est un LSR qui est un LSR sortant, mais qui possède également un ou plusieurs LSR directement connectés en aval. Pour un nœud bud, le trafic du chemin principal en amont est transféré vers un LSR en aval. Si le chemin principal en amont échoue, le trafic MPLS du chemin de sauvegarde en amont est transféré vers le LSR en aval. Cela signifie que le saut suivant LSR en aval est ajouté aux deux routes MPLS ainsi qu’au saut suivant sortant.

Comme avec PIM, vous activez le MoFRR avec LDP multipoint à l’aide de l’énoncé stream-protection de configuration dans la [edit routing-options multicast] hiérarchie, et il est géré par un ensemble de stratégies de filtre.

Si vous avez activé le fec LDP multipoint point à multipoint pour MoFRR, l’équipement tient compte des considérations suivantes dans la sélection du chemin en amont :

• Les sessions LDP ciblées sont ignorées s’il y a une session LDP non ciblée. S’il y a une seule session LDP ciblée, la session LDP ciblée est sélectionnée, mais le FEC point à multipoint correspondant perd la capacité MoFRR parce qu’aucune interface n’est associée à la session LDP ciblée.

• Toutes les interfaces appartenant au même LSR en amont sont considérées comme le chemin principal.

• Pour toute mise à jour de routage de nœud racine, le chemin en amont est modifié en fonction des derniers sauts de l’IGP. Si un meilleur chemin est disponible, le LDP multipoint tente de passer au meilleur chemin.

Transfert de paquets

Pour le PIM ou le LDP multipoint, l’équipement effectue la sélection de flux source multicast au niveau de l’interface entrante. Cela permet de préserver la bande passante de la structure et d’optimiser les performances de transfert, car il :

• Évite d’envoyer des flux en double à travers la structure

• Empêche les recherches de routes multiples (qui entraînent des pertes de paquets).

Pour le PIM, chaque flux multicast IP contient la même adresse de destination. Quelle que soit l’interface sur laquelle les paquets arrivent, les paquets ont le même chemin. L’équipement vérifie l’interface sur laquelle chaque paquet arrive et transfère uniquement ceux qui sont à partir de l’interface principale. Si l’interface correspond à une interface de flux de secours, l’équipement abandonne les paquets. Si l’interface ne correspond ni à l’interface principale ni à l’interface de flux de secours, l’équipement gère les paquets comme des exceptions dans le plan de contrôle.

Figure 13 affiche ce processus avec des exemples d’interfaces primaires et de secours pour les routeurs avec PIM. Figure 14 montre cela de même pour les commutateurs avec PIM.

Pour le MoFRR avec LDP multipoint sur les routeurs, l’équipement utilise plusieurs étiquettes MPLS pour contrôler la sélection des flux MoFRR. Chaque étiquette représente une route distincte, mais chaque référence à la même vérification de la liste d’interface. L’équipement transfère uniquement le label principal et abandonne toutes les autres. Plusieurs interfaces peuvent recevoir des paquets à l’aide du même label.

Figure 15 montre ce processus pour les routeurs avec LDP multipoint.

Limites et mises en garde

• Limites et mises en garde du MoFRR sur les équipements de commutation et de routage
• Limites du MoFRR sur les équipements de commutation avec PIM
• Limites et mises en garde du MoFRR sur les équipements de routage avec multipoint LDP

Présentation du routage de segments vers l’interopérabilité LDP

Figure 22 affiche une topologie de réseau LDP simple pour illustrer comment fonctionne l’interopérabilité des équipements de routage de segments avec les équipements LDP. Gardez à l’esprit que les deux OSPF et ISIS sont pris en charge, donc pour l’instant nous garderons les choses agnostiques en ce qui concerne l’IGP. L’exemple de topologie comprend six équipements, de R1 à R6, dans un réseau en cours de migration de LDP vers le routage de segments.

Dans la topologie, les équipements R1, R2 et R3 sont configurés uniquement pour le routage de segments. Les équipements R5 et R6 font partie d’un domaine LDP hérité et ne prennent pas actuellement en charge le SR. L’équipement R4 prend en charge à la fois le LDP et le routage de segments. Les adresses de bouclage de tous les équipements sont affichées. Ces bouclages sont annoncés en tant que FEC sortants dans le domaine LDP et en tant qu’ID de nœud SR dans le domaine SR. L’interopérabilité repose sur le mappage d’un FEC LDP sur un ID de nœud SR, et vice versa.

Pour que le R1 soit compatible avec le protocole R6, un serveur de mappage de segments LDP (SRMS) et un client SRMC (Segment Routing Mapping) sont nécessaires. Il est plus facile de comprendre le rôle du SRMS et du SRMC en examinant le flux de trafic de manière unidirectionnelle. Figure 22D’après , nous allons dire que le trafic circulant de gauche à droite provient du domaine SR et se termine dans le domaine LDP. De la même manière, le trafic qui circule de droite à gauche provient du domaine LDP et se termine dans le domaine SR.

Le SRMS fournit les informations nécessaires pour assembler le trafic en direction de gauche à droite. Le SRMC permet de cartographier le trafic qui circule de droite à gauche.

• Flux de trafic de gauche à droite : Serveur de mappage de segments

  Le SRMS facilite l’assemblage LSP entre les domaines SR et LDP. Le serveur mappe les FECs LDP en ID de nœud SR. Vous configurez les FECs LDP pour qu’ils soient mappés au niveau hiérarchique [edit routing-options source-packet-routing] . Normalement, vous devez mapper toutes les adresses de bouclage de nœud LDP pour une connectivité complète. Comme illustré ci-dessous, vous pouvez mapper les préfixes contigus dans une seule instruction de plage. Si les boucles de nœud LDP ne sont pas contiguës, vous devez définir plusieurs instructions de mappage.

  Vous appliquez la configuration de mappage SRMS au niveau ou [edit protocols isis] hiérarchique[edit protocols ospf]. Ce choix dépend de l’IGP utilisé. Notez que les nœuds SR et LDP partagent tous deux un même domaine de routage IGP, zone/niveau.

  Le SRMS génère une liste de préfixes étendue LSA (ou LSP dans le cas d’ISIS). Les informations contenues dans ce LSA permettent aux nœuds SR de mapper les préfixes LDP (FEC) aux ID de nœud SR. Les routes mappées pour les préfixes LDP sont installées dans les inet.3 tables de mpls.0 routage des nœuds SR pour faciliter les opérations d’entrée et d’assemblage LSP pour le trafic dans le sens gauche-droite.

  La LSA étendue (ou LSP) est inondée dans toute la zone IGP (unique). Cela signifie que vous êtes libre de placer la configuration SRMS sur n’importe quel routeur du domaine SR. Le nœud SRMS n’a pas à exécuter LDP.

• Flux de trafic de droite à gauche : Le client de mappage de segments

  Pour interagir de droite à gauche, c’est-à-dire de l’île LDP à l’île SR, il suffit d’activer la fonctionnalité client de mappage de segments sur un nœud qui parle à la fois SR et LDP. Dans notre exemple, C’est le R4. Vous activez la fonctionnalité SRMC avec l’instruction mapping-client dans la [edit protocols ldp] hiérarchie.

  La configuration SRMC active automatiquement une stratégie de sortie LDP pour annoncer les SIDs de nœud et de préfixe du domaine SR en tant que FEC sortants LDP. Cela fournit aux nœuds LDP une accessibilité LSP aux nœuds du domaine SR.

• La fonction SRMC doit être configurée sur un routeur qui se fixe à la fois aux domaines SR et LSP. Si vous le souhaitez, le même nœud peut également fonctionner comme le SRMS.

Routage de segments vers l’interopérabilité LDP à l’aide d’OSPF

Reportez-vous à Figure 22, supposons que d’eviceR2 (dans le réseau de routage de segments) est le SRMS.

1. Définir la fonction SRMS :

   Cette configuration crée un bloc de mappage pour les deux adresses de bouclage des équipements LDP dans la topologie de l’exemple. L’index SID (Segment ID) initial mappé au bouclage de R5 est 1000. La spécification de la taille 2 permet de mapper l’index SID 10001 à l’adresse de bouclage de R6.

   REMARQUE :

   L’adresse IP utilisée comme start-prefix adresse de bouclage d’un équipement du réseau LDP (R5, dans cet exemple). Pour une connectivité complète, vous devez mapper toutes les adresses de bouclage des routeurs LDP dans le domaine SR. Si les adresses de bouclage sont contiguës, vous pouvez le faire avec une seule prefix-segment-range instruction. Les bouclages non contigus nécessitent la définition de plusieurs instructions de mappage de préfixes.

   Notre exemple utilise des bouclages contigus, de sorte qu’un seul prefix-segment-range est illustré ci-dessus. Voici un exemple de mappages multiples pour prendre en charge le cas de deux nœuds LDP avec un adressage de bouclage non contigu :

2. Ensuite, configurez la prise en charge d’OSPF pour le LSA étendu utilisé pour inonder les préfixes mappés.

   Une fois que la configuration du serveur de mappage est validée sur l’équipement R2, la plage de préfixes étendue TLV est inondée dans la zone OSPF. Les équipements capables de routage de segments (R1, R2 et R3) installent des routes de routage de segments OSPF pour l’adresse de bouclage spécifiée (R5 et R6 dans cet exemple), avec un index ID de segment (SID). L’index SID est également mis à jour dans la mpls.0 table de routage par les équipements de routage de segments.

3. Activez la fonctionnalité SRMC. Pour notre topologie d’exemple, vous devez activer la fonctionnalité SRMC sur R4.

   Une fois que la configuration du client de mappage est validée sur l’équipement R4, les ID de nœud SR et les blocs d’étiquettes sont annoncés en tant que FEC sortants vers le routeur R5, qui les annonce à nouveau sur R6.

La prise en charge du routage de segments et des sauts suivants LDP avec OSPF a commencé dans Junos OS 19.1R1.

Unsupported Features and Functionality for Segment Routing interoperability with LDP using OSPF

• Les conflitsde préfixes ne sont détectés qu’au niveau du SRMS. En cas de conflit de plage de préfixes, le SID de préfixe de l’ID de routeur inférieur prévaut. Dans ce cas, un message d’erreur deRPD_OSPF_PFX_SID_RANGE_CONFLICT journal système est généré.

• Les préfixes IPv6 ne sont pas pris en charge.

• L’inondation du préfixe OSPF LSA opaque sur les frontières AS (inter-AS) n’est pas prise en charge.

• La fonctionnalité de mappage LDP inter-zone du serveur n’est pas prise en charge.

• La fonctionnalité ABR de LSA opaque de préfixe étendu n’est pas prise en charge.

• La fonctionnalité ASBR de LSA opaque de préfixe étendu n’est pas prise en charge.

• Le TLV de préférence serveur de routage de routage n’estpas pris en charge.

Interopérabilité du routage de segments avec LDP à l’aide d’ISIS

Reportez-vous à Figure 22, supposons que l’équipement R2 (dans le réseau de routage de segments) est le SRMS. La configuration suivante est ajoutée pour la fonction de mappage :

1. Définir la fonction SRMS :

   Cette configuration crée un bloc de mappage pour les deux adresses de bouclage des équipements LDP dans la topologie de l’exemple. L’index INITIAL d’ID de segment (SID) mappé au bouclage de R5 est 1000. La spécification de la taille 2 permet de mapper l’index SID 10001 à l’adresse de bouclage de R6.

   REMARQUE :

   L’adresse IP utilisée comme start-prefix adresse de bouclage d’un équipement du réseau LDP (R5, dans cet exemple). Pour une connectivité complète, vous devez mapper toutes les adresses de bouclage des routeurs LDP du domaine SR. Si les adresses de bouclage sont contiguës, vous pouvez le faire avec une prefix-segment-range instruction. Les bouclages non contigus nécessitent la définition de plusieurs instructions de mappage.

   Notre exemple utilise des bouclages contigus, de sorte qu’un seul prefix-segment-range est illustré ci-dessus. Voici un exemple de mappage de préfixes pour gérer le cas de deux routeurs LDP avec un adressage de bouclage non contigu :

2. Ensuite, configurez la prise en charge d’ISIS pour le LSP étendu utilisé pour inonder les préfixes mappés.

   Une fois que la configuration du serveur de mappage est validée sur l’équipement R2, la plage de préfixes étendue TLV est inondée dans la zone OSPF. Les équipements capables de routage de segments (R1, R2 et R3) installent des routes de routage de segments ISIS pour l’adresse de bouclage spécifiée (R5 et R6 dans cet exemple), avec un index d’ID de segment (SID). L’index SID est également mis à jour dans la mpls.0 table de routage par les équipements de routage de segments.

3. Activez la fonctionnalité SRMC. Pour notre topologie d’exemple, vous devez activer la fonctionnalité SRMC sur R4.

   Une fois la configuration client de mappage validée sur l’équipement R4, les ID de nœud SR et les blocs d’étiquettes sont annoncés en tant que FEC sortants vers le routeur R5, puis vers le R6.

La prise en charge du routage de segments et des sauts suivants LDP avec ISIS a commencé dans Junos OS 17.4R1.

Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using ISIS

• Les TLV de liaison d’étiquettes ne sont pas prises en charge.

• La publicité de la gamme de préfixes dans les TLV de liaison d’étiquettes n’est pas prise en charge.

• La résolution des conflits de routage de segments n’est pas prise en charge.

• Les statistiques de trafic LDP ne fonctionnent pas.

• Le routage actif sans interruption (NSR) et le basculement GRES (Graceful Routing Engine Switchover) ne sont pas pris en charge.

• Isis inter-niveau n’est pas pris en charge.

• RFC 7794, Attributs de préfixe IS-IS pour L’IPv4 étendu n’est pas pris en charge.

• La redistribution du routage LDP en tant que préfixe-sid au niveau du nœud d’assemblage n’est pas prise en charge.

Configurer le LDP pour utiliser la métrique de route IGP

Utilisez l’instruction track-igp-metric si vous souhaitez que la métrique de route IGP (Interior Gateway Protocol) soit utilisée pour les routes LDP au lieu de la métrique de route LDP par défaut (la métrique de route LDP par défaut est 1).

Pour utiliser la métrique de route IGP, incluez l’énoncé track-igp-metric :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

Empêcher l’ajout de routes entrantes à la table de routage inet.0

En configurant l’instruction no-forwarding , vous pouvez empêcher l’ajout de routes entrantes à la table de routage inet.0 au lieu de la table de routage inet.3, même si vous avez activé l’instruction traffic-engineering bgp-igp au niveau de la [edit protocols mpls] ou de la [edit logical-systems logical-system-name protocols mpls] hiérarchie. Par défaut, l’instruction no-forwarding est désactivée.

REMARQUE :

Les routeurs ACX Series ne prennent pas en charge le niveau hiérarchique [edit logical-systems].

Pour omettre les routes entrantes de la table de routage inet.0, incluez l’instruction no-forwarding :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

VPN LDP et opérateur d’opérateurs multiples

En configurant plusieurs instances de routage LDP, vous pouvez utiliser LDP pour faire la publicité des étiquettes dans un VPN de fournisseur de services, d’un routeur pe (Fournisseur de services) à un routeur de périphérie client (CE) opérateur client. Cela est particulièrement utile lorsque le client opérateur est un fournisseur de services Internet de base (FAI) et souhaite restreindre l’intégralité des routes Internet à ses routeurs PE. En utilisant LDP au lieu de BGP, le client opérateur protège ses autres routeurs internes d’Internet. Le LDP à plusieurs instances est également utile lorsqu’un client opérateur souhaite fournir des services VPN de couche 2 ou 3 à ses clients.

Pour obtenir un exemple de configuration de plusieurs instances de routage LDP pour les VPN opérateur-de-carriers, consultez le Guide de l’utilisateur sur plusieurs instances pour le protocole de distribution d’étiquettes.

Configurez MPLS et LDP pour que l’étiquette s’affiche sur le routeur Ultimate-Hop

Le label annoncé par défaut est label 3 (label Null implicite). Si le label 3 est annoncé, l’avant-dernier saut retire le label et envoie le paquet au routeur de sortie. Si le saut ultime est activé, le label 0 (label IPv4 Explicit Null) est annoncé. Le saut ultime garantit que tous les paquets traversant un réseau MPLS comprennent une étiquette.

Pour configurer le saut ultime, incluez l’énoncé explicit-null :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

REMARQUE :

Les routeurs Juniper Networks mettez en file d’attente les paquets en fonction du label entrant. Les routeurs d’autres fournisseurs peuvent mettre en file d’attente les paquets différemment. Gardez cela à l’esprit lorsque vous travaillez avec des réseaux contenant des routeurs de plusieurs fournisseurs.

Pour plus d’informations sur les étiquettes, voir Présentation des étiquettes MPLS et Allocation de labels MPLS.

Activer le LDP sur les LSP établis par RSVP

Vous pouvez exécuter LDP sur des LSP établis par RSVP, en tunnelisant efficacement le LSP établi par LDP via celui établi par RSVP. Pour ce faire, activez LDP sur l’interface lo0.0 (voir Activation et désactivation du LDP). Vous devez également configurer les LSP sur lesquels vous souhaitez que le LDP fonctionne en incluant l’instruction ldp-tunneling au niveau de la [edit protocols mpls label-switched-path lsp-name] hiérarchie :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

REMARQUE :

Le LDP peut être tunnelisé sur une session RSVP dont la protection de liaison est activée. À partir de Junos OS Release 21.1R1, l’affichage des détails sur le routage tunnelisé LDP affiche à la fois les sauts suivants primaires et de contournement LSP. Dans les versions précédentes de Junos OS, le saut suivant LSP de contournement affichait le saut suivant pour le LSP principal.

Activer le LDP sur les LSP établis par RSVP dans des réseaux hétérogènes

D’autres fournisseurs utilisent une métrique OSPF de 1 pour l’adresse de bouclage. Les routeurs Juniper Networks utilisent une métrique OSPF de 0 pour l’adresse de bouclage. Pour cela, vous devrez peut-être configurer manuellement la métrique RSVP lors du déploiement de tunnelisation LDP sur des LSP RSVP dans des réseaux hétérogènes.

Lorsqu’un routeur Juniper Networks est lié au routeur d’un autre fournisseur via un tunnel RSVP, et que la tunnelisation LDP est également activée, par défaut, le routeur Juniper Networks peut ne pas utiliser le tunnel RSVP pour acheminer le trafic vers les destinations LDP en aval du routeur sortant de l’autre fournisseur si le chemin RSVP a une mesure de 1 plus grande que le chemin OSPF physique.

Pour vous assurer que la tunnelisation LDP fonctionne correctement dans des réseaux hétérogènes, vous pouvez configurer OSPF pour ignorer la métrique LSP RSVP en incluant l’énoncé ignore-lsp-metrics :

Vous pouvez configurer cette déclaration aux niveaux hiérarchiques suivants :

• [edit protocols ospf traffic-engineering shortcuts]

• [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]

REMARQUE :

Les routeurs ACX Series ne prennent pas en charge le niveau hiérarchique [edit logical-systems].

Pour activer le LDP sur les LSP RSVP, vous devez également effectuer la procédure dans la section Activer le LDP sur les LSP établis par RSVP.

Configurer la signature TCP MD5 pour les sessions LDP

Vous pouvez configurer une signature MD5 pour une connexion TCP LDP afin de vous protéger contre l’introduction de segments TCP usurpés dans les flux de connexion de session LDP. Pour plus d’informations sur l’authentification TCP, voir TCP. Pour savoir comment utiliser l’option d’authentification TCP (TCP-AO) au lieu de TCP MD5, reportez-vous à la section No link title.

Un routeur utilisant l’option de signature MD5 est configuré avec un mot de passe pour chaque pair pour lequel l’authentification est requise. Le mot de passe est stocké chiffré.

Des adjacencies LDP hello peuvent encore être créées même lorsque les interfaces d’appairage sont configurées avec différentes signatures de sécurité. Toutefois, la session TCP ne peut pas être authentifiée et n’est jamais établie.

Vous pouvez configurer HMAC (Hashed Message Authentication Code) et l’authentification MD5 pour les sessions LDP en tant que configuration par session ou configuration de correspondance de sous-réseau (c’est-à-dire la correspondance de préfixe la plus longue). La prise en charge de l’authentification par correspondance de sous-réseau permet de configurer l’authentification pour les sessions LDP (TLDP) ciblées automatiquement. Cela facilite le déploiement de l’alternative sans boucle à distance (LFA) et des pseudowires FEC 129.

Pour configurer une signature MD5 pour une connexion TCP LDP, incluez l’instruction dans le authentication-key groupe de sessions :

Utilisez l’instruction session-group pour configurer l’adresse pour la fin distante de la session LDP.

Le md5-authentication-key, ou mot de passe, dans la configuration peut avoir jusqu’à 69 caractères. Les caractères peuvent inclure n’importe quelle chaîne ASCII. Si vous incluez des espaces, joignez tous les caractères entre guillemets.

Vous pouvez également configurer un mécanisme de mise à jour des clés d’authentification pour le protocole de routage LDP. Ce mécanisme vous permet de mettre à jour les clés d’authentification sans interrompre les protocoles de routage et de signalisation associés tels que Open Shortest Path First (OSPF) et le protocole RSVP (Resource Reservation Setup Protocol).

Pour configurer le mécanisme de mise à jour des clés d’authentification, incluez l’instruction key-chain au niveau de la [edit security authentication-key-chains] hiérarchie et spécifiez l’option key de créer un trousseau comprenant plusieurs clés d’authentification.

Pour configurer le mécanisme de mise à jour des clés d’authentification pour le protocole de routage LDP, incluez l’instruction authentication-key-chain au niveau de la [edit protocols ldp] hiérarchie afin d’associer le protocole aux clés d’authentification [edit security suthentication-key-chains] . Vous devez également configurer l’algorithme d’authentification en incluant l’instruction authentication-algorithm algorithm au niveau hiérarchique [edit protocols ldp] .

Pour plus d’informations sur la fonctionnalité de mise à jour des clés d’authentification, voir Configuration du mécanisme de mise à jour des clés d’authentification pour les protocoles de routage BGP et LDP.

Configuration de la protection des sessions LDP

Une session LDP est normalement créée entre une paire de routeurs connectés par une ou plusieurs liaisons. Les routeurs forment un bonjour adjacence pour chaque liaison qui les connecte et associent toutes les adjacenances à la session LDP correspondante. Lorsque la dernière adjacence bonjour pour une session LDP disparaît, la session LDP est terminée. Vous pouvez modifier ce comportement pour éviter qu’une session LDP ne soit inutilement interrompue et rétablie.

Vous pouvez configurer Junos OS pour qu’il laisse la session LDP entre deux routeurs, même s’il n’y a pas d’adjacencies de bonjour sur les liaisons reliant les deux routeurs en configurant l’instruction session-protection . Vous pouvez éventuellement spécifier un temps en quelques secondes à l’aide de l’option timeout . La session reste en cours pendant la durée spécifiée tant que les routeurs maintiennent la connectivité réseau IP.

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section Résumé de l’instruction.

Désactiver les pièges SNMP pour LDP

Chaque fois qu’un LSP LDP effectue une transition de haut en bas ou de bas en haut, le routeur envoie un piège SNMP. Cependant, il est possible de désactiver les pièges SNMP LDP sur un routeur, un système logique ou une instance de routage.

Pour plus d’informations sur les pièges SNMP LDP et la MIB LDP propriétaire, consultez l’Explorateur MIB SNMP.

Pour désactiver les pièges SNMP pour LDP, spécifiez l’option trap disable de l’instruction log-updown :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

Configuration de la synchronisation LDP avec l’IGP sur les liaisons LDP

LDP est un protocole permettant de distribuer des étiquettes dans des applications non conçues pour le trafic. Les étiquettes sont distribuées le long du meilleur chemin déterminé par l’IGP. Si la synchronisation entre LDP et IGP n’est pas maintenue, le LSP tombe en panne. Lorsque le LDP n’est pas pleinement opérationnel sur un lien donné (une session n’est pas établie et les labels ne sont pas échangés), l’IGP annonce la liaison avec la mesure du coût maximal. La liaison n’est pas privilégiée, mais reste dans la topologie du réseau.

La synchronisation LDP n’est prise en charge que sur les interfaces point à point actives et les interfaces LAN configurées en tant que point à point dans le cadre de l’IGP. La synchronisation LDP n’est pas prise en charge lors d’un redémarrage progressif.

Pour annoncer la mesure du coût maximal jusqu’à ce que le LDP soit opérationnel pour la synchronisation, incluez l’énoncé ldp-synchronization :

Pour désactiver la synchronisation, incluez l’instruction disable . Pour configurer la période de temps afin d’annoncer la mesure du coût maximal d’une liaison qui n’est pas entièrement opérationnelle, incluez l’énoncé hold-time .

Pour obtenir une liste des niveaux hiérarchiques sur lesquels vous pouvez configurer cette instruction, consultez la section récapitulatif de l’instruction pour cette déclaration.

Configuration de la synchronisation LDP avec l’IGP sur le routeur

Vous pouvez configurer le temps d’attente du LDP avant d’informer l’IGP que le voisin LDP et la session d’une interface sont opérationnels. Pour les grands réseaux avec de nombreux FEC, vous devrez peut-être configurer une valeur plus longue pour laisser suffisamment de temps pour que les bases de données d’étiquettes LDP soient échangées.

Pour configurer le temps d’attente du LDP avant d’informer l’IGP que le voisin LDP et la session sont opérationnels, incluez l’instruction igp-synchronization et spécifiez un temps en secondes pour l’option holddown-interval :

Pour obtenir une liste des niveaux hiérarchiques sur lesquels vous pouvez configurer cette instruction, consultez la section récapitulatif de l’instruction pour cette déclaration.

Configuration du timer de retrait des étiquettes

Le timer de retrait d’étiquettes retarde l’envoi d’un message de retrait d’étiquette pour une FEC à un voisin. Lorsqu’une liaison IGP vers un voisin échoue, le label associé au FEC doit être retiré de tous les routeurs en amont si le voisin est le saut suivant pour le FEC. Une fois que l’IGP a convergé et qu’un label a été reçu d’un nouveau saut suivant, le label est lus vers tous les routeurs en amont. C’est le comportement typique du réseau. En retardant le retrait des étiquettes d’un petit temps (par exemple, jusqu’à ce que l’IGP converge et que le routeur reçoive un nouveau label pour le FEC du saut suivant en aval), le retrait de label et l’envoi d’un mappage de labels pourraient être évités. L’instruction label-withdrawal-delay vous permet de configurer ce délai. Par défaut, le délai est de 60 secondes.

Si le routeur reçoit le nouveau label avant que le timer n’arrive à s’écouler, le timer de retrait de label est annulé. Toutefois, si le timer s’exécute, le label du FEC est retiré de tous les routeurs en amont.

Par défaut, le LDP attend 60 secondes avant de retirer les labels pour éviter que les LSP démissionnent plusieurs fois pendant que l’IGP se reconverge. Pour configurer le délai de retrait des étiquettes en quelques secondes, incluez l’énoncé label-withdrawal-delay :

Pour obtenir une liste des niveaux hiérarchiques sur lesquels vous pouvez configurer cette instruction, consultez la section récapitulatif de l’instruction pour cette déclaration.

Ignorer la vérification des sous-réseaux LDP

Dans junos OS version 8.4 et versions ultérieures, une vérification du sous-réseau d’adresse source LDP est effectuée pendant la procédure d’établissement du voisin. L’adresse source de la liaison LDP hello packet est associée à l’adresse de l’interface. Cela entraîne un problème d’interopérabilité avec les équipements d’autres fournisseurs.

Pour désactiver la vérification du sous-réseau, incluez l’énoncé allow-subnet-mismatch :

Cette déclaration peut être incluse aux niveaux hiérarchiques suivants :

• [edit protocols ldp interface interface-name]

• [edit logical-systems logical-system-name protocols ldp interface interface-name]

REMARQUE :

Les routeurs ACX Series ne prennent pas en charge le niveau hiérarchique [edit logical-systems].

Sortie des statistiques LDP

L’exemple de sortie suivant provient d’un fichier de statistiques LDP :

Le fichier de statistiques LDP comprend les colonnes de données suivantes :

• FEC— FEC pour lesquels des statistiques de trafic LDP sont collectées.

• Type— Type de trafic provenant d’un routeur, soit Ingress (provenant de ce routeur) soit Transit (transféré via ce routeur).

• Packets— Nombre de paquets passés par le FEC depuis l’arrivée de son LSP.

• Bytes— Nombre d’octets de données transmises par le FEC depuis l’arrivée de son LSP.

• Shared: une Yes valeur indique que plusieurs préfixes sont liés au même label (par exemple, lorsque plusieurs préfixes sont annoncés avec une stratégie de sortie). Les statistiques de trafic LDP pour ce cas s’appliquent à tous les préfixes et doivent être traitées comme telles.

• read— Ce nombre (qui apparaît à côté de la date et de l’heure) peut différer du nombre réel des statistiques affichées. Certaines des statistiques sont résumées avant d’être affichées.

Désactiver les statistiques LDP sur l’avant-dernier saut du routeur

La collecte de statistiques de trafic LDP au niveau de l’avant-dernier routeur peut consommer des ressources système excessives, en particulier sur les routes à sauts suivants. Ce problème est exacerbé si vous avez configuré l’instruction deaggregate en plus de l’instruction traffic-statistics . Pour les routeurs qui atteignent leur limite d’utilisation du routage suivant, nous vous recommandons de configurer l’option no-penultimate-hop pour l’instruction traffic-statistics :

Pour obtenir une liste des niveaux hiérarchiques sur lesquels vous pouvez configurer l’instruction traffic-statistics , consultez la section récapitulatif de l’instruction pour cette déclaration.

REMARQUE :

Lorsque vous configurez l’option no-penultimate-hop , aucune statistique n’est disponible pour les FEC qui constituent l’avant-dernier saut pour ce routeur.

Chaque fois que vous incluez ou supprimez cette option de la configuration, les sessions LDP sont supprimées, puis redémarrées.

L’exemple de sortie suivant provient d’un fichier de statistiques LDP montrant les routeurs sur lesquels l’option no-penultimate-hop est configurée :

Limites des statistiques LDP

Les problèmes liés à la collecte de statistiques LDP par la configuration de l’instruction sont les traffic-statistics suivants :

• Vous ne pouvez pas effacer les statistiques LDP.

• Si vous raccourcissez l’intervalle spécifié, une nouvelle demande de statistiques LDP n’est émise que si le timer de statistiques expire plus tard que le nouvel intervalle.

• Une nouvelle opération de collecte de statistiques LDP ne peut pas commencer tant que la précédente n’est pas terminée. Si l’intervalle est court ou si le nombre de statistiques LDP est important, l’intervalle entre les deux collections de statistiques peut être plus long que l’intervalle.

Lorsqu’un LSP tombe en panne, les statistiques LDP sont réinitialisées.

Traçage du trafic du protocole LDP aux niveaux du protocole et de l’instance de routage

Pour tracer le trafic du protocole LDP, vous pouvez spécifier des options dans l’instruction globale traceoptions au niveau de la [edit routing-options] hiérarchie, et vous pouvez spécifier des options spécifiques à LDP en incluant l’instruction traceoptions :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

Utilisez l’instruction file pour spécifier le nom du fichier qui reçoit le résultat de l’opération de suivi. Tous les fichiers sont placés dans le répertoire /var/log. Nous vous recommandons de placer la sortie LDP-tracing dans le fichier ldp-log.

Les indicateurs de trace suivants affichent les opérations associées à l’envoi et à la réception de divers messages LDP. Chacun peut porter un ou plusieurs des modificateurs suivants :

• address— Suivre le fonctionnement des messages d’adresse et de retrait d’adresse.

• binding— Tracez les opérations de liaison d’étiquettes.

• error: suivre les conditions d’erreur.

• event— Suivre les événements du protocole.

• initialization— Suivre le fonctionnement des messages d’initialisation.

• label: tracez le fonctionnement des messages de demande d’étiquettes, de mappage d’étiquettes, de retrait d’étiquettes et de libération de label.

• notification— Suivre le fonctionnement des messages de notification.

• packets— Tracez le fonctionnement de l’adresse, le retrait d’adresse, l’initialisation, la demande d’étiquette, le plan de label, le retrait d’étiquettes, la libération des étiquettes, les notifications et les messages périodiques. Ce modificateur équivaut à définir le address, initialization, label, notificationet periodic les modificateurs.

  Vous pouvez également configurer le filter modificateur d’indicateur avec la match-on address sous-option pour l’indicateur packets . Cela vous permet de tracer en fonction des adresses source et de destination des paquets.

• path— Suivre les opérations de chemin de commutation d’étiquettes.

• path— Suivre les opérations de chemin de commutation d’étiquettes.

• periodic— Tracez le fonctionnement des messages bonjour et keepalive.

• route— Suivre le fonctionnement des messages de routage.

• state— Suivre les transitions d’état du protocole.

Traçage du trafic du protocole LDP au sein des FEC

Le LDP associe une classe d’équivalence de transfert (FEC) à chaque LSP qu’il crée. Le FEC associé à un LSP spécifie quels paquets sont mappés à ce LSP. Les LSP sont étendus via un réseau puisque chaque routeur choisit le label annoncé par le saut suivant pour le FEC et l’splice au label qu’il annonce à tous les autres routeurs.

Vous pouvez tracer le trafic du protocole LDP dans un FEC spécifique et filtrer les déclarations de trace LDP en fonction d’un FEC. Cela est utile lorsque vous souhaitez tracer ou dépanner le trafic de protocole LDP associé à un FEC. Les indicateurs de trace suivants sont disponibles à cette fin : route, pathet binding.

L’exemple suivant illustre comment configurer l’instruction LDP traceoptions pour filtrer les instructions de trace LDP en fonction d’un FEC :

Cette fonctionnalité présente les limites suivantes :

• La fonctionnalité de filtrage n’est disponible que pour les FEC composés de préfixes IP version 4 (IPv4).

• Les CIRCUITS de couche 2 ne peuvent pas être filtrés.

• Lorsque vous configurez à la fois le routage et le filtrage, les routes MPLS ne s’affichent pas (elles sont bloquées par le filtre).

• Le filtrage est déterminé par la stratégie et la valeur configurée pour l’option match-on . Lors de la configuration de la stratégie, assurez-vous que le comportement par défaut est toujours reject.

• La seule match-on option est fec. Par conséquent, le seul type de stratégie à inclure est une stratégie de filtre de routage.

Exemples: Suivi du trafic du protocole LDP

Tracez en détail les messages de chemin LDP :

Suivre tous les messages sortants LDP :

Tracez toutes les conditions d’erreur LDP :

Tracez tous les messages entrants LDP et toutes les opérations de liaison d’étiquettes :

Tracez le trafic du protocole LDP pour un FEC associé au LSP :