Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Sur cette page
 

LDP Configuration

Configuration LDP minimale

Pour activer LDP avec une configuration minimale :

  1. Activez toutes les interfaces pertinentes dans la famille MPLS. Dans le cas d’un LDP dirigé, l’interface de bouclage doit être activée avec la famille MPLS.

  2. (Facultatif) Configurez les interfaces appropriées au niveau de la [edit protocol mpls] hiérarchie.

  3. Activez LDP sur une seule interface, incluez l’instruction et spécifiez l’interface à l’aide de l’instruction ldpinterface .

Il s’agit de la configuration LDP minimale. Toutes les autres instructions de configuration LDP sont facultatives.

Pour activer LDP sur toutes les interfaces, spécifiez all pour interface-name.

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure ces relevés, reportez-vous aux sections récapitulatives des relevés.

Activation et désactivation de LDP

LDP est conscient des instances de routage. Pour activer LDP sur une interface spécifique, incluez les instructions suivantes :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure ces relevés, reportez-vous aux sections récapitulatives des relevés.

Pour activer LDP sur toutes les interfaces, spécifiez all pour interface-name.

Si vous avez configuré des propriétés d’interface sur un groupe d’interfaces et que vous souhaitez désactiver LDP sur l’une d’elles, incluez l’instruction avec l’option interfacedisable :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de la déclaration.

Configuration du minuteur LDP pour Hello Messages

Les messages Hello LDP permettent aux nœuds LDP de se découvrir les uns les autres et de détecter la défaillance d’un voisin ou le lien avec le voisin. Des messages Hello sont envoyés périodiquement sur toutes les interfaces sur lesquelles LDP est activé.

Il existe deux types de messages de bonjour LDP :

  • Link hello messages : envoyés via l’interface LDP sous forme de paquets UDP adressés au port de découverte LDP. La réception d’un message de bonjour de lien LDP sur une interface identifie une contiguïté avec le routeur homologue LDP.

  • Messages d’accueil ciblés : envoyés sous forme de paquets UDP adressés au port de découverte LDP à une adresse spécifique. Les messages hello ciblés sont utilisés pour prendre en charge les sessions LDP entre des routeurs qui ne sont pas directement connectés. Un routeur ciblé détermine s’il doit répondre ou ignorer un message de bonjour ciblé. Un routeur ciblé qui choisit de répondre le fait en renvoyant périodiquement des messages de bonjour ciblés au routeur à l’origine.

Par défaut, LDP envoie des messages hello toutes les 5 secondes pour les messages hello de lien et toutes les 15 secondes pour les hello messages ciblés. Vous pouvez configurer le minuteur LDP pour modifier la fréquence d’envoi des deux types de messages hello. Toutefois, vous ne pouvez pas configurer une heure pour le minuteur LDP supérieure à la durée de maintien LDP. Pour plus d’informations, reportez-vous à la section Configuration du délai avant que les voisins LDP ne soient considérés comme inactifs.

Configuration du minuteur LDP pour les messages Link Hello

Pour modifier la fréquence à laquelle LDP envoie des messages hello de lien, spécifiez un nouvel intervalle de message hello link pour le temporisateur LDP à l’aide de l’instruction hello-interval suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Configuration du minuteur LDP pour les messages Hello ciblés

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

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure ces instructions, reportez-vous aux sections de résumé des instructions pour ces instructions.

Configuration du délai avant que les voisins LDP ne soient considérés comme inactifs

Le temps d’attente détermine combien de temps un nœud LDP doit attendre un message de bonjour avant de déclarer qu’un voisin est en panne. Cette valeur est envoyée dans le cadre d’un message hello afin que chaque nœud LDP indique à ses voisins combien de temps attendre. Il n’est pas nécessaire que les valeurs envoyées par chaque voisin correspondent.

Le temps d’attente doit normalement être d’au moins trois fois l’intervalle hello. La valeur par défaut est de 15 secondes pour les messages de bonjour de lien et de 45 secondes pour les messages de bonjour ciblés. Cependant, il est possible de configurer un temps de maintien LDP proche de la valeur de l’intervalle hello.

REMARQUE :

En configurant un temps de maintien LDP proche de l’intervalle hello (moins de trois fois l’intervalle hello), les défaillances du voisin LDP peuvent être détectées plus rapidement. Cependant, cela augmente également la possibilité que le routeur déclare un voisin LDP inactif qui fonctionne toujours normalement. Pour plus d’informations, reportez-vous à la section Configuration du minuteur LDP pour Hello Messages.

Le temps d’attente LDP est également négocié automatiquement entre les homologues LDP. Lorsque deux homologues LDP annoncent des temps de maintien LDP différents, la valeur la plus petite est utilisée. Si un routeur homologue LDP annonce un temps d’attente plus court que la valeur que vous avez configurée, le temps d’attente annoncé du routeur homologue est utilisé. Cette négociation peut également affecter l’intervalle de maintien en vie LDP.

Si le temps de maintien LDP local n’est pas raccourci pendant la négociation de l’homologue LDP, l’intervalle keepalive configuré par l’utilisateur reste inchangé. Toutefois, si le temps de maintien local est réduit pendant la négociation entre pairs, l’intervalle de rétention est recalculé. Si le temps de mise en attente LDP a été réduit pendant la négociation entre pairs, l’intervalle de rétention est réduit à un tiers de la nouvelle valeur de temps de mise en attente. Par exemple, si la nouvelle valeur de temps de maintien est de 45 secondes, l’intervalle keepalive est défini sur 15 secondes.

Ce calcul automatisé de l’intervalle de rétention peut entraîner la configuration de différents intervalles de rétention sur chaque routeur homologue. Cela permet aux routeurs d’être flexibles quant à la fréquence à laquelle ils envoient des messages persistants, car la négociation d’homologue LDP garantit qu’ils sont envoyés plus fréquemment que le temps d’attente LDP.

Lorsque vous reconfigurez l’intervalle de temps d’attente, les modifications ne prennent effet qu’après la réinitialisation de la session. Le temps d’attente est négocié lorsque la session d’appairage LDP est initiée et ne peut pas être renégocié tant que la session est active (requis par la RFC 5036, spécification LDP). Pour forcer manuellement la réinitialisation de la session LDP, exécutez la clear ldp session commande.

Configuration du temps d’attente LDP pour les messages Link Hello

Pour modifier la durée pendant laquelle un noeud LDP doit attendre un message hello de liaison avant de déclarer le voisin en panne, spécifiez une nouvelle heure en secondes à l’aide de l’instruction hold-time :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

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

Pour modifier la durée pendant laquelle un nœud LDP doit attendre un message hello ciblé avant de déclarer le voisin en panne, spécifiez une nouvelle durée en secondes à l’aide de l’instruction comme option pour l’instruction hold-timetargeted-hello :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure ces instructions, reportez-vous aux sections de résumé des instructions pour ces instructions.

Activation des messages Hello ciblés stricts pour LDP

Utilisez des messages d’accueil ciblés stricts pour empêcher l’établissement de sessions LDP avec des voisins distants qui n’ont pas été configurés spécifiquement. Si vous configurez l’instruction, un homologue LDP ne répond pas aux messages hello ciblés provenant d’une source qui n’est pas l’un strict-targeted-hellos de ses voisins distants configurés. Les voisins distants configurés peuvent inclure :

  • Points de terminaison des tunnels RSVP pour lesquels la tunnelisation LDP est configurée

  • Voisins de circuit de couche 2

Si un voisin non configuré envoie un message hello, l’homologue LDP ignore le message et consigne une erreur (avec l’indicateur de error trace) indiquant la source. Par exemple, si l’homologue LDP a reçu un bonjour ciblé de l’adresse Internet 10.0.0.1 et qu’aucun voisin avec cette adresse n’est spécifiquement configuré, le message suivant est imprimé dans le fichier journal LDP :

Pour activer les messages hello ciblés stricts, incluez l’instruction strict-targeted-hellos suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Configuration de l’intervalle pour les messages persistants LDP

L’intervalle keepalive détermine la fréquence à laquelle un message est envoyé au cours de la session pour s’assurer que le délai d’expiration du keepalive n’est pas dépassé. Si aucun autre trafic LDP n’est envoyé sur la session pendant ce laps de temps, un message keepalive est envoyé. La valeur par défaut est de 10 secondes. La valeur minimale est de 1 seconde.

La valeur configurée pour l’intervalle keepalive peut être modifiée lors de la négociation de session LDP si la valeur configurée pour le temps de maintien LDP sur le routeur homologue est inférieure à la valeur configurée localement. Pour plus d’informations, reportez-vous à la section Configuration du délai avant que les voisins LDP ne soient considérés comme inactifs.

Pour modifier l’intervalle keepalive, incluez l’instruction keepalive-interval suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Configuration du délai d’expiration de LDP Keepalive

Une fois qu’une session LDP est établie, des messages doivent être échangés régulièrement pour s’assurer que la session fonctionne toujours. Le délai d’expiration keepalive définit le temps d’attente du nœud LDP voisin avant de décider de l’échec de la session. Cette valeur est généralement définie sur au moins trois fois l’intervalle keepalive. La valeur par défaut est de 30 secondes.

Pour modifier l’intervalle keepalive, incluez l’instruction keepalive-timeout suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

La valeur configurée pour l’instruction s’affiche en tant que temps d’attente keepalive-timeout lorsque vous exécutez la show ldp session detail commande.

Configuration de la correspondance la plus longue pour LDP

Afin de permettre à LDP d’apprendre les routes agrégées ou résumées à travers les zones OSPF ou les niveaux ISIS dans inter -domain, Junos OS vous permet de configurer la correspondance la plus longue pour LDP en fonction de RFC5283.

Avant de configurer la correspondance la plus longue pour LDP, vous devez procéder comme suit :

  1. Configurez les interfaces de l’appareil.

  2. Configurez le protocole MPLS .

  3. Configurez le protocole OSPF.

Pour configurer la correspondance la plus longue pour LDP, vous devez procéder comme suit :

  1. Configurez la correspondance la plus longue pour le protocole LDP.
  2. Configurez le protocole LDP sur l’interface.

    Par exemple, pour configurer les interfaces :

Exemple : Configuration de la correspondance la plus longue pour LDP

Cet exemple montre comment configurer la correspondance la plus longue pour LDP en fonction de RFC5283. Cela permet à LDP d’apprendre les routes agrégées ou résumées à travers les zones OSPF ou les niveaux ISIS dans l’inter-domaine. La stratégie de correspondance la plus longue fournit une granularité par préfixe.

Conditions préalables

Cet exemple utilise les composants matériels et logiciels suivants :

  • Six routeurs MX Series avec protocole OSPF et LDP activé sur les interfaces connectées.

  • Junos OS version 16.1 ou ultérieure s’exécute sur tous les équipements.

Avant de commencer :

  • Configurez les interfaces de l’appareil.

  • Configurez OSPF.

Présentation

Le LDP est souvent utilisé pour établir des chemins de commutation d’étiquettes (LSP) MPLS sur l’ensemble d’un domaine réseau à l’aide d’un IGP tel qu’OSPF ou IS-IS. Dans un tel réseau, tous les liens du domaine ont des adjacences IGP ainsi que des adjacences LDP. Le protocole LDP établit les LSP sur le chemin le plus court vers une destination déterminée par le transfert IP. Sous Junos OS, l’implémentation LDP effectue une recherche de correspondance exacte sur l’adresse IP de la FEC dans les routes RIB ou IGP pour le mappage d’étiquettes. Ce mappage exact nécessite la configuration des adresses IP des points de terminaison MPLS LDP de bout en bout dans tous les LER. Cela va à l’encontre de l’objectif de la conception hiérarchique IP ou du routage par défaut dans les équipements d’accès. La configuration longest-match permet de surmonter ce problème en supprimant le comportement de correspondance exact et en configurant LSP en fonction de l’itinéraire de correspondance le plus long par préfixe.

Topologie

Dans la topologie, Figure 1indique que la correspondance la plus longue pour LDP est configurée sur l’appareil R0 .

Figure 1 : Exemple de correspondance la plus longue pour LDPExemple de correspondance la plus longue pour LDP

Configuration

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.

R0

R1

R2

R3

R4

R5

Configuration de l’appareil R0

Procédure étape par étape

L’exemple suivant nécessite que vous naviguiez à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.

Pour configurer l’appareil R0 :

  1. Configurez les interfaces.

  2. Attribuez les adresses de bouclage à l’appareil.

  3. Configurez l’ID du routeur.

  4. Configurez le protocole MPLS sur l’interface.

  5. Configurez le protocole OSPF sur l’interface.

  6. Configurez la correspondance la plus longue pour le protocole LDP.

  7. Configurez le protocole LDP sur l’interface.

Résultats

À partir du mode de configuration, confirmez votre configuration en saisissant les commandes show interfaces, show protocolset show routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé de configurer l’appareil, entrez-le commit à partir du mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification des itinéraires

But

Vérifiez que les itinéraires attendus sont appris.

Action

Sur le périphérique R0, à partir du mode opérationnel, exécutez la commande pour afficher les routes dans la show route table de routage.

Sens

La sortie affiche toutes les routes de la table de routage du périphérique R0.

Vérification des informations de présentation du PLD

But

Afficher les informations de présentation de LDP.

Action

Sur l’appareil R0, à partir du mode opérationnel, exécutez la commande pour afficher la show ldp overview vue d’ensemble du LDP.

Sens

La sortie affiche les informations de vue d’ensemble LDP de l’appareil R0

Vérifiez les entrées LDP dans la table de topologie interne.

But

Affichez les entrées de route dans la table de topologie interne du protocole de distribution d’étiquettes (LDP).

Action

Sur l’appareil R0, à partir du mode opérationnel, exécutez la commande pour afficher la show ldp route table de topologie interne de LDP.

Sens

La sortie affiche les entrées de route dans la table de topologie interne LDP (Label Distribution Protocol) de l’équipement R0.

Vérifier uniquement les informations FEC du routage LDP

But

Affichez uniquement les informations FEC du routage LDP.

Action

Sur le périphérique R0, à partir du mode opérationnel, exécutez la commande pour afficher les routes dans la show ldp route fec-only table de routage.

Sens

La sortie affiche uniquement les routes FEC du protocole LDP disponibles pour l’appareil R0.

Vérifier les routes FEC et Shadow de LDP

But

Affichez la FEC et les routes fantômes dans la table de routage.

Action

Sur le périphérique R0, à partir du mode opérationnel, exécutez la commande pour afficher les routes FEC et shadow dans la show ldp route fec-and-route table de routage.

Sens

La sortie affiche la FEC et les routes d’ombre de l’appareil R0

Configuration des préférences de routage LDP

Lorsque plusieurs protocoles calculent des routes vers la même destination, les préférences de route sont utilisées pour sélectionner la route installée dans la table de transfert. L’itinéraire avec la valeur de préférence la plus faible est sélectionné. La valeur de préférence peut être un nombre compris entre 0 et 255. Par défaut, les routes LDP ont une valeur de préférence de 9.

Pour modifier les préférences d’itinéraire, incluez l’instruction preference suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Redémarrage progressif de LDP

Le redémarrage progressif LDP permet à un routeur dont le plan de contrôle LDP est en cours de redémarrage de continuer à transférer le trafic tout en récupérant son état à partir des routeurs voisins. Il active également un routeur sur lequel le mode d’assistance est activé pour aider un routeur voisin qui tente de redémarrer LDP.

Lors de l’initialisation de session, un routeur annonce sa capacité à effectuer un redémarrage progressif LDP ou à tirer parti d’un voisin effectuant un redémarrage progressif LDP en envoyant le TLV de redémarrage progressif. Ce TLV contient deux champs pertinents pour le redémarrage progressif LDP : le temps de reconnexion et le temps de récupération. Les valeurs des temps de reconnexion et de récupération indiquent les capacités de redémarrage progressif prises en charge par le routeur.

Lorsqu’un routeur découvre qu’un routeur voisin est en train de redémarrer, il attend la fin du temps de récupération avant de tenter de se reconnecter. Le temps de récupération correspond à la durée pendant laquelle un routeur attend que 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 à la durée pendant laquelle un routeur voisin conserve ses informations sur le routeur qui redémarre, ce qui lui permet de continuer à transférer le trafic.

Vous pouvez configurer le redémarrage progressif LDP à la fois dans l’instance principale pour le protocole LDP et pour une instance de routage spécifique. Vous pouvez désactiver le redémarrage progressif au niveau global pour tous les protocoles, au niveau du protocole pour LDP uniquement et sur une instance de routage spécifique. Le redémarrage progressif LDP est désactivé par défaut, car au niveau global, le redémarrage progressif est désactivé par défaut. Toutefois, le mode d’assistance (la possibilité d’assister un routeur voisin qui tente un redémarrage progressif) est activé par défaut.

Voici quelques-uns des comportements associés au redémarrage normal de LDP :

  • Les étiquettes sortantes ne sont pas conservées lors des redémarrages. De nouveaux labels sortants sont attribués.

  • Lorsqu’un routeur redémarre, aucun message de mappage d’étiquettes n’est envoyé aux voisins qui prennent en charge le redémarrage normal jusqu’à ce que le routeur de redémarrage se soit stabilisé (les messages de mappage d’étiquettes sont immédiatement envoyés aux voisins qui ne prennent pas en charge le redémarrage normal). Cependant, tous les autres messages (keepalive, address-message, notification et release) sont envoyés comme d’habitude. La distribution de ces autres messages empêche le routeur de diffuser des informations incomplètes.

  • Le mode d’assistance et le redémarrage progressif sont indépendants. Vous pouvez désactiver le redémarrage progressif dans la configuration, tout en autorisant le routeur à coopérer avec un voisin qui tente de redémarrer correctement.

Configuration du redémarrage progressif de LDP

Lorsque vous modifiez la configuration du redémarrage progressif au niveau de la hiérarchie ou de [edit protocols ldp graceful-restart] la hiérarchie, toute session LDP en cours d’exécution est automatiquement redémarrée pour appliquer la [edit routing-options graceful-restart] configuration du redémarrage progressif. Ce comportement reflète le comportement de BGP lorsque vous modifiez sa configuration de redémarrage progressif.

Par défaut, le mode d’assistance au redémarrage progressif est activé, mais le redémarrage progressif est désactivé. Ainsi, le comportement par défaut d’un routeur est d’aider les routeurs voisins qui tentent un redémarrage progressif, mais pas de tenter un redémarrage progressif lui-même.

Pour configurer le redémarrage progressif de LDP, reportez-vous aux sections suivantes :

Activation du redémarrage progressif

Pour activer le redémarrage progressif LDP, vous devez également activer le redémarrage progressif sur le routeur. Pour activer le redémarrage normal, incluez l’instruction graceful-restart suivante :

Vous pouvez inclure cette instruction 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 normal, reportez-vous à la bibliothèque des protocoles de routage de Junos OS pour les périphériques de routage.

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

Désactivation du mode de redémarrage progressif ou du mode d’assistance LDP

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

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Vous ne pouvez désactiver le mode d’assistance qu’au niveau des protocoles LDP. 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’instruction helper-disable suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

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 correctement, 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 le redémarrage progressif LDP ni le type, la longueur et la valeur de redémarrage progressif (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 normal 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 reconnexion

Après l’échec de la connexion LDP entre les voisins, les voisins attendent un certain temps que le routeur redémarre normalement pour reprendre l’envoi de messages LDP. Une fois la période d’attente terminée, la session LDP peut être rétablie. Vous pouvez configurer la période d’attente en secondes. Cette valeur est incluse dans le TLV de session tolérant aux pannes envoyé dans les messages d’initialisation LDP lorsque le redémarrage normal LDP est activé.

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

Pour configurer l’heure de reconnexion, incluez l’instruction reconnect-time suivante :

Vous pouvez définir le temps de reconnexion sur une valeur comprise entre 30 et 300 secondes. Par défaut, elle est de 60 secondes.

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez configurer ces instructions, reportez-vous aux sections récapitulatives des instructions pour ces instructions.

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

Le temps de récupération correspond au temps qu’un routeur attend que 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 à la durée pendant laquelle un routeur voisin conserve ses informations sur le routeur qui redémarre, ce qui lui permet de continuer à transférer le trafic.

Pour éviter qu’un routeur voisin ne soit affecté négativement s’il reçoit une valeur fausse pour le temps de récupération du routeur redémarrant, vous pouvez configurer le temps de récupération maximal sur le routeur voisin. Un routeur voisin conserve 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’attendra que 400 secondes avant de purger ses informations LDP du routeur A.

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

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez configurer ces instructions, reportez-vous aux sections récapitulatives des instructions pour ces instructions.

Filtrage des liaisons d’étiquettes LDP entrantes

Vous pouvez filtrer les liaisons d’étiquettes LDP reçues, en appliquant des stratégies pour accepter ou refuser les liaisons annoncées par les routeurs voisins. Pour configurer le filtrage des étiquettes reçues, incluez l’instruction import suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

La stratégie nommée (configurée au niveau de la [edit policy-options] hiérarchie) est appliquée à toutes les liaisons d’étiquettes reçues de tous les voisins LDP. Tout le filtrage est effectué à l’aide d’instructions. répertorie les seuls from opérateurs qui s’appliquent from au filtrage des étiquettes reçues LDP. Tableau 1

Tableau 1 : des opérateurs qui s’appliquent au filtrage LDP des étiquettes reçues

from Opérateur

Description

interface

Correspondances sur les liaisons reçues d’un voisin adjacent sur l’interface spécifiée

neighbor

Correspondances sur les liaisons reçues de l’ID de routeur LDP spécifié

next-hop

Correspondances sur les liaisons reçues d’un voisin annonçant l’adresse d’interface spécifiée

route-filter

Correspondances sur les liaisons avec le préfixe spécifié

Si une liaison est filtrée, elle apparaît toujours dans la base de données LDP, mais ne peut pas être installée dans le cadre d’un chemin de commutation d’étiquettes (LSP).

En règle générale, l’application de stratégies dans LDP ne peut être utilisée que pour bloquer l’établissement de LSP, et non pour contrôler leur routage. En effet, le chemin suivi par un LSP est déterminé par le routage unicast, et non par LDP. Toutefois, lorsqu’il existe plusieurs chemins d’accès à coût égal vers la destination via différents voisins, vous pouvez utiliser le filtrage LDP pour exclure certains des sauts suivants possibles de la prise en compte. (Sinon, LDP choisit l’un des sauts suivants possibles au hasard.)

Les sessions LDP ne sont pas liées à des interfaces ou adresses d’interface. LDP n’annonce que des étiquettes par routeur (et non par interface) ; Ainsi, s’il existe plusieurs liaisons parallèles entre deux routeurs, une seule session LDP est établie, et elle n’est pas liée à une seule interface. Lorsqu’un routeur a plusieurs contiguïtés par rapport au même voisin, veillez à ce que le filtre fasse ce qui est attendu. (En règle générale, l’utilisation de et interface n’est next-hop pas appropriée dans ce cas.)

Si une étiquette a été filtrée (c’est-à-dire qu’elle a été rejetée par la stratégie et qu’elle n’est pas utilisée pour construire un LSP), elle est marquée comme filtrée dans la base de données :

Pour plus d’informations sur la configuration des stratégies pour LDP, consultez le Guide de l’utilisateur Stratégies de routage, filtres de pare-feu et mécanismes de contrôle du trafic.

Exemples: Filtrage des liaisons d’étiquettes LDP entrantes

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

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

Filtrage des liaisons d’étiquettes LDP sortantes

Vous pouvez configurer des stratégies d’exportation pour filtrer les étiquettes sortantes LDP. Vous pouvez filtrer les liaisons d’étiquettes sortantes en appliquant des stratégies de routage pour empêcher les liaisons d’être annoncées aux routeurs voisins. Pour configurer le filtrage des étiquettes sortantes, incluez l’instruction export suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

La stratégie d’exportation nommée (configurée au niveau de la [edit policy-options] hiérarchie) est appliquée à toutes les liaisons d’étiquettes transmises à tous les voisins LDP. Le seul from opérateur qui s’applique au filtrage d’étiquettes sortantes LDP est route-filter, qui fait correspondre les liaisons avec le préfixe spécifié. Les seuls to opérateurs qui s’appliquent au filtrage d’étiquettes sortantes sont les opérateurs de Tableau 2.

Tableau 2 : aux opérateurs pour le filtrage d’étiquettes sortantes LDP

à l’opérateur

Description

interface

Correspondances sur les liaisons envoyées à un voisin adjacent sur l’interface spécifiée

neighbor

Correspondances sur les liaisons envoyées à l’ID de routeur LDP spécifié

next-hop

Correspondances sur les liaisons envoyées à un voisin annonçant l’adresse d’interface spécifiée

Si une liaison est filtrée, elle n’est pas annoncée au routeur voisin, mais elle peut être installée dans le cadre d’un LSP sur le routeur local. Vous pouvez appliquer des stratégies dans LDP pour bloquer l’établissement de prestataires de services linguistiques, mais pas pour contrôler leur routage. Le chemin suivi par un LSP est déterminé par le routage unicast, et non par LDP.

Les sessions LDP ne sont pas liées à des interfaces ou adresses d’interface. LDP n’annonce que des étiquettes par routeur (et non par interface). S’il existe plusieurs liaisons parallèles entre deux routeurs, une seule session LDP est établie et elle n’est pas liée à une seule interface.

N’utilisez pas les next-hop opérateurs et interface lorsqu’un routeur a plusieurs contiguïtés par rapport au même voisin.

Les étiquettes filtrées sont marquées dans la base de données :

Pour plus d’informations sur la configuration des stratégies pour LDP, consultez le Guide de l’utilisateur Stratégies de routage, filtres de pare-feu et mécanismes de contrôle du trafic.

Exemples: Filtrage des liaisons d’étiquettes LDP sortantes

Bloquez la transmission de l’itinéraire à 10.10.255.6/32 tous les voisins :

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

Spécification de l’adresse de transport utilisée par LDP

Les routeurs doivent d’abord établir une session TCP entre eux avant de pouvoir établir une session LDP. La session TCP permet aux routeurs d’échanger les annonces d’étiquettes nécessaires à la session LDP. Pour établir la session TCP, chaque routeur doit connaître l’adresse de transport de l’autre routeur. L’adresse de transport est une adresse IP utilisée pour identifier la session TCP sur laquelle la session LDP s’exécutera.

Pour configurer l’adresse de transport LDP, incluez l’instruction transport-address :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Si vous spécifiez l’option, l’adresse de l’identificateur de routeur est utilisée comme adresse de transport (sauf configuration contraire, l’identificateur de routeur est généralement le même que l’adresse router-id de bouclage). Si vous spécifiez cette option, l’adresse de l’interface est utilisée comme adresse de transport pour toutes les sessions LDP vers les voisins qui peuvent être atteints via cette interface interface. Notez que l’identifiant du routeur est utilisé comme adresse de transport par défaut.

REMARQUE :

Pour que le fonctionnement se fasse correctement, l’adresse de transport LDP doit être accessible. L’ID de routeur est un identifiant, pas une adresse IP routable. Pour cette raison, il est recommandé que l’ID du routeur soit défini pour correspondre à l’adresse de bouclage et que l’adresse de bouclage soit annoncée par l’IGP.

Vous ne pouvez pas spécifier l’option interface lorsqu’il existe plusieurs liaisons parallèles vers le même voisin LDP, car la spécification LDP exige que la même adresse de transport soit annoncée sur toutes les interfaces vers le même voisin. Si LDP détecte plusieurs liaisons parallèles vers le même voisin, il désactive les interfaces vers ce voisin une par une jusqu’à ce que la condition soit effacée, soit en déconnectant le voisin sur une interface, soit en spécifiant l’option router-id .

Adresse de transport de contrôle utilisée pour la session LDP ciblée

Pour établir une session TCP entre deux périphériques, chaque équipement doit apprendre l’adresse de transport de l’autre équipement. L’adresse de transport est une adresse IP utilisée pour identifier la session TCP sur laquelle la session LDP fonctionne. Auparavant, cette adresse de transport ne pouvait être que l’ID du routeur ou une adresse d’interface. Grâce à la fonctionnalité d’adresse de transport LDP, vous pouvez configurer explicitement n’importe quelle adresse IP en tant qu’adresse de transport pour les voisins LDP ciblés pour les circuits de couche 2, MPLS et VPLS. Cela vous permet de contrôler les sessions LDP ciblées à l’aide de la configuration des adresses de transport.

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 le réseau dorsal IGP pour LDP. Cela permet des opérations fluides et faciles.

Vue d’ensemble des adresses de transport LDP ciblées

Avant Junos OS version 19.1R1, LDP ne prenait en charge que l’ID de routeur ou l’adresse d’interface en tant qu’adresse de transport sur toute interface LDP. Les contiguïtés formées sur cette interface utilisaient l’une des adresses IP attribuées à l’interface ou à l’ID du routeur. En cas de contiguïté ciblée, l’interface est l’interface de bouclage. Lorsque plusieurs adresses de bouclage étaient configurées sur l’équipement, l’adresse de transport de l’interface ne pouvait pas être dérivée et, par conséquent, la session LDP ne pouvait pas être établie.

À partir de Junos OS version 19.1R1, 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 comme adresse de transport sous les sessioninstructions de configuration , session-groupet interface . La configuration de l’adresse de transport ne s’applique qu’aux voisins configurés, y compris les circuits de couche 2, les adjacences MPLS et VPLS. Cette configuration ne s’applique pas aux contiguïtés découvertes (ciblées ou non).

Préférence 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 sessions 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 ciblé (configurée via la configuration circuit de couche 2, MPLS, VPLS et LDP) est le suivant :

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

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

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

  4. Sous [edit protocols ldp] la 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] la hiérarchie.

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

  3. Adresse par défaut.

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

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

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

  3. Adresse par défaut.

Dépannage de la configuration de l’adresse de transport

Vous pouvez utiliser les sorties de commande show suivantes pour dépanner les 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 hello au voisin ciblé. Si cette adresse n’est pas joignable depuis le voisin, la session LDP ne s’affiche pas.

  • show configuration protocols ldp

Vous pouvez également activer les traceoptions LDP pour un dépannage plus poussé.

  • Si l’on remplace l’utilisation d’une adresse de transport non valide (non accessible) par une adresse de transport valide, les traces suivantes peuvent être observées :

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

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

  • Vérifiez l’icône address family. L’adresse de transport configurée sous l’instruction doit appartenir à la même famille d’adresses session que le voisin ou la session.

  • L’adresse configurée en tant qu’adresse de transport sous une neighbor instruction ou session doit être locale au routeur pour que les messages hello ciblés démarrent. 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.

Configuration des préfixes annoncés dans LDP à partir de la table de routage

Vous pouvez contrôler l’ensemble des préfixes annoncés dans LDP et faire en sorte que le routeur soit le routeur de sortie pour ces préfixes. Par défaut, seule l’adresse de bouclage est annoncée dans LDP. Pour configurer l’ensemble de préfixes de la table de routage à annoncer dans LDP, incluez l’instruction egress-policy suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

REMARQUE :

Si vous configurez une stratégie de sortie pour LDP qui n’inclut pas l’adresse de bouclage, elle n’est plus annoncée dans LDP. Pour continuer à publier l’adresse de bouclage, vous devez la configurer explicitement dans le cadre de la stratégie de sortie LDP.

La stratégie nommée (configurée au niveau ou [edit policy-options][edit logical-systems logical-system-name policy-options] hiérarchie) est appliquée à tous les itinéraires de la table de routage. Les routes qui correspondent à la stratégie sont annoncées dans LDP. Vous pouvez contrôler l’ensemble des voisins auxquels ces préfixes sont annoncés à l’aide de l’instruction export . Seuls les from opérateurs sont pris en compte, vous pouvez utiliser n’importe quel opérateur valide from . Pour plus d’informations, reportez-vous à la bibliothèque de protocoles de routage de Junos OS pour les périphériques de routage.

REMARQUE :

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

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

Annoncez tous les itinéraires connectés dans LDP :

Configuration de la désagrégation FEC

Lorsqu’un routeur de sortie LDP annonce plusieurs préfixes, ceux-ci sont liés à une étiquette unique et agrégés en une seule classe d’équivalence de transfert (FEC). Par défaut, LDP conserve cette agrégation lorsque la publication traverse le réseau.

Normalement, étant donné qu’un LSP n’est pas réparti sur plusieurs sauts suivants et que les préfixes sont liés en un seul LSP, l’équilibrage de charge sur les chemins à coût égal ne se produit pas. Toutefois, vous pouvez équilibrer la charge sur des chemins à coût égal si vous configurez une stratégie d’équilibrage de charge et désagrégez les FEC.

La désagrégation des FEC entraîne la liaison de chaque préfixe à une étiquette distincte et devient un LSP distinct.

Pour configurer des FEC désagrégées, incluez l’instruction deaggregate suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Pour toutes les sessions LDP, vous ne pouvez configurer des FEC désagrégées que globalement.

La désagrégation d’une FEC permet aux LSP multiples qui en résultent d’être distribués sur plusieurs chemins à coût égal et distribue les LSP sur les multiples sauts suivants sur les segments de sortie, mais n’installe qu’un seul saut suivant par LSP.

Pour agréger les FEC, incluez l’énoncé no-deaggregate suivant :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Pour toutes les sessions LDP, vous ne pouvez configurer des FEC agrégées que globalement.

Configuration des mécanismes de contrôle pour les FEC LDP

Vous pouvez configurer Junos OS pour suivre et contrôler le trafic pour les FEC LDP. Les mécanismes de contrôle FEC LDP peuvent être utilisés pour effectuer l’une des opérations suivantes :

  • Suivez ou contrôlez le trafic entrant pour détecter un FEC LDP.

  • Suivre ou surveiller le trafic de transit pour un FEC LDP.

  • Suivez ou contrôlez le trafic LDP FEC provenant d’une classe de transfert spécifique.

  • Suivez ou contrôlez le trafic FEC LDP provenant d’un site VRF (Virtual Routing and Forwarding) spécifique.

  • Ignorez le trafic faux lié à une FEC LDP spécifique.

Pour contrôler le trafic d’une FEC LDP, vous devez d’abord configurer un filtre. Plus précisément, vous devez configurer l’instruction ou l’instruction interfaceinterface-set au niveau de la [edit firewall family protocol-family filter filter-name term term-name from] hiérarchie. L’instruction interface vous permet de faire correspondre le filtre à une seule interface. L’instruction interface-set vous permet de faire correspondre le filtre à plusieurs interfaces.

Pour plus d’informations sur la configuration de l’instruction, de l’instruction et des mécanismes de contrôle pour les FEC LDP, consultez le Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et des mécanismes de contrôle du trafic.interfaceinterface-set

Une fois que vous avez configuré les filtres, vous devez les inclure dans la configuration de l’instruction policing pour LDP. Pour configurer les mécanismes de contrôle pour les FEC LDP, incluez l’instruction policing suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

La policing déclaration comprend les options suivantes :

  • fec: spécifiez l’adresse FEC de la FEC LDP que vous souhaitez contrôler.

  • ingress-filter: spécifiez le nom du filtre de trafic entrant.

  • transit-traffic: spécifiez le nom du filtre de trafic de transit.

Configuration du filtrage FEC LDP IPv4

Par défaut, lorsqu’une session LDP ciblée est établie, Junos OS échange toujours les classes d’équivalence de transfert IPv4 (FEC) et les FEC de circuit de couche 2 sur la session LDP ciblée. Dans le cas d’une session LDP vers un voisin indirectement connecté, vous ne souhaiterez peut-être exporter les FEC de circuit de couche 2 vers le voisin que si la session a été spécifiquement configurée pour prendre en charge les circuits de couche 2 ou VPLS.

Dans un réseau de fournisseurs mixtes où tous les préfixes non-BGP sont annoncés dans LDP, la base de données LDP peut devenir volumineuse. Pour ce type d’environnement, il peut être utile d’empêcher la publication de FEC IPv4 sur des sessions LDP créées en raison d’une configuration VPLS de circuit de couche 2 ou LDP. De même, il peut être utile de filtrer les FEC IPv4 reçues dans ce type d’environnement.

Si tous les voisins LDP associés à une session LDP sont de couche 2 uniquement, vous pouvez configurer Junos OS pour annoncer uniquement les FEC de circuit de couche 2 en configurant l’instruction l2-smart-policy . Cette fonctionnalité filtre également automatiquement les FEC IPv4 reçus au cours de cette session. La configuration d’une stratégie d’exportation ou d’importation explicite activée pour l2-smart-policy désactive cette fonctionnalité dans la direction correspondante.

Si l’un des voisins de la session LDP est formé en raison d’une contiguïté découverte ou si la contiguïté est formée en raison d’une configuration de tunnelisation LDP sur un ou plusieurs LSP RSVP, les FEC IPv4 sont annoncés et reçus en utilisant le comportement par défaut.

Pour empêcher LDP d’exporter des FEC IPv4 sur des sessions LDP avec des voisins de couche 2 uniquement et pour filtrer les FEC IPv4 reçus au cours de ces sessions, incluez l’instruction l2-smart-policy suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez configurer cette instruction, reportez-vous au résumé de cette instruction.

Configuration de BFD pour les LSP LDP

Vous pouvez configurer la détection de transfert bidirectionnel (BFD) pour les LSP LDP. Le protocole BFD est un mécanisme hello simple qui détecte les défaillances dans un réseau. Les paquets Hello sont envoyés à un intervalle spécifié et régulier. Une défaillance de voisinage est détectée lorsque le routeur cesse de recevoir une réponse après un intervalle spécifié. BFD fonctionne avec une grande variété d’environnements et de topologies réseau. Les temporisateurs de détection des défaillances pour BFD ont des limites de temps plus courtes que les mécanismes de détection des défaillances des routes statiques, ce qui permet une détection plus rapide.

Une erreur est consignée chaque fois qu’une session BFD pour un chemin échoue. La solution suivante montre comment les messages de journal BFD pour LDP LSP peuvent s’afficher :

Vous pouvez également configurer BFD pour les LSP RSVP, comme décrit dans Configuration de BFD pour les LSP avec signal RSVP.

Les minuteries de détection de défaillance BFD sont adaptatives et peuvent être ajustées pour être plus ou moins agressives. Par exemple, les temporisateurs peuvent s’adapter à une valeur plus élevée si la contiguïté échoue, ou un voisin peut négocier une valeur plus élevée pour un temporisateur que la valeur configurée. Les temporisateurs s’adaptent à une valeur plus élevée lorsqu’un battement de session BFD se produit plus de trois fois en l’espace de 15 secondes. Un algorithme d’interruption augmente l’intervalle de réception (Rx) de deux si l’instance BFD locale est à l’origine de l’interruption de session. L’intervalle de transmission (Tx) est augmenté de deux si l’instance BFD distante est à l’origine de l’interruption de session. Vous pouvez utiliser la clear bfd adaptation commande pour ramener les temporisateurs d’intervalle BFD à leurs valeurs configurées. La clear bfd adaptation commande est sans impact, ce qui signifie qu’elle n’affecte pas le flux de trafic sur le périphérique de routage.

Pour activer BFD pour les LSP LDP, incluez les oam instructions et bfd-liveness-detection :

Vous pouvez activer BFD pour les LSP LDP associés à une classe d’équivalence de transfert (FEC) spécifique en configurant l’adresse FEC à l’aide de l’option au niveau de fec la [edit protocols ldp] hiérarchie. Vous pouvez également configurer une stratégie d’entrée OAM (Operation Administration and Management) pour activer BFD sur une plage d’adresses FEC. Pour plus d’informations, consultez Configuration des stratégies d’entrée OAM pour LDP.

Vous ne pouvez pas activer les LSP LSP BFD LDP à moins que leurs adresses FEC équivalentes ne soient explicitement configurées ou qu’OAM ne soit activé sur les FEC à l’aide d’une stratégie d’entrée OAM. Si BFD n’est pas activé pour les adresses FEC, la session BFD ne s’affichera pas.

Vous pouvez configurer l’instruction oam aux niveaux hiérarchiques suivants :

  • [edit protocols ldp]

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

REMARQUE :

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

La oam déclaration comprend les options suivantes :

  • fec: spécifiez l’adresse FEC. Vous devez spécifier une adresse FEC ou configurer une stratégie d’entrée OAM pour vous assurer que la session BFD est activée.

  • lsp-ping-interval: spécifiez la durée de l’intervalle ping LSP en secondes. Pour émettre un ping sur un LSP signalé par LDP, utilisez la ping mpls ldp commande. Pour plus d’informations, consultez l’Explorateur CLI.

La bfd-liveness-detection déclaration comprend les options suivantes :

  • ecmp: permet à LDP d’établir des sessions BFD pour tous les chemins ECMP configurés pour la FEC spécifiée. Si vous configurez l’option, vous devez également configurer l’instruction ecmpperiodic-traceroute pour la FEC spécifiée. Si vous ne le faites pas, l’opération de validation échoue. Vous pouvez configurer l’instruction periodic-traceroute au niveau de la hiérarchie globale () tout en ne configurant l’option ecmp que pour une FEC spécifique ([edit protocols ldp oam][edit protocols ldp oam fec address bfd-liveness-detection]).

  • holddown-interval : spécifiez la durée pendant laquelle la session BFD doit rester active avant d’ajouter l’itinéraire ou le saut suivant. La spécification d’une durée de 0 seconde entraîne l’ajout de l’itinéraire ou du saut suivant dès que la session BFD est rétablie.

  • minimum-interval: spécifie l’intervalle minimal d’émission et de réception. Si vous configurez l’option, vous n’avez pas besoin de configurer l’option ou l’option minimum-intervalminimum-receive-intervalminimum-transmit-interval .

  • minimum-receive-interval: spécifie l’intervalle de réception minimal. La plage est comprise entre 1 et 255 000 millisecondes.

  • minimum-transmit-interval: spécifie l’intervalle de transmission minimal. La plage est comprise entre 1 et 255 000 millisecondes.

  • multiplier: spécifiez le multiplicateur de temps de détection. La plage va de 1 à 255.

  • version : spécifiez la version BFD. Les options sont BFD version 0 ou BFD version 1. Par défaut, le logiciel Junos OS tente de déterminer automatiquement la version BFD.

Configuration d’un BFD compatible ECMP pour les LSP LDP

Lorsque vous configurez BFD pour une FEC, une session BFD est établie pour un seul next-hop local actif pour le routeur. Toutefois, vous pouvez configurer plusieurs sessions BFD, une pour chaque FEC associée à un chemin ECMP (Equal-cost Multipath) spécifique. Pour que cela fonctionne correctement, vous devez également configurer le traceroute périodique LDP LSP. ( Reportez-vous à la section Configuration de LDP LSP Traceroute.) Le traceroute LSP LDP est utilisé pour découvrir les chemins ECMP. Une session BFD est lancée pour chaque chemin ECMP découvert. Chaque fois qu’une session BFD pour l’un des chemins ECMP échoue, une erreur est consignée.

Le traceroute LSP LDP est exécuté régulièrement pour vérifier l’intégrité des chemins ECMP. Lorsqu’un problème est détecté, les événements suivants peuvent se produire :

  • Si le dernier traceroute LSP LDP pour une FEC diffère du traceroute précédent, les sessions BFD associées à cette FEC (les sessions BFD pour les plages d’adresses qui ont changé par rapport à l’exécution précédente) sont arrêtées et de nouvelles sessions BFD sont initiées pour les adresses de destination dans les plages modifiées.

  • Si le traceroute LSP LDP renvoie une erreur (par exemple, un délai d’expiration), toutes les sessions BFD associées à cette FEC sont détruites.

Pour configurer LDP afin d’établir des sessions BFD pour tous les chemins ECMP configurés pour la FEC spécifiée, incluez l’instruction ecmp .

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Avec l’instruction, vous devez également inclure l’instruction, soit dans la configuration OAM LDP globale (au niveau de la hiérarchie ou ), soit dans la configuration de la FEC spécifiée (au niveau de la [edit protocols ldp oam][edit protocols ldp oam fec address] hiérarchie ou [edit logical-systems logical-system-name protocols ldp oam][edit logical-systems logical-system-name protocols ldp oam fec address] ).ecmpperiodic-traceroute Dans le cas contraire, l’opération de validation échoue.

REMARQUE :

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

Configuration d’une action d’échec pour la session BFD sur un LSP LDP

Vous pouvez configurer les propriétés route et next-hop en cas d’échec de session BFD sur un LSP LDP. Il peut s’agir d’une session BFD existante qui est tombée en panne ou d’une session BFD qui n’est jamais apparue. LDP rajoute l’itinéraire ou le saut suivant lorsque la session BFD correspondante est rétablie.

Vous pouvez configurer l’une des options d’action d’échec suivantes pour l’instruction en cas d’échec d’une failure-action session BFD sur le LSP LDP :

  • remove-nexthop: supprime la route correspondant au tronçon suivant de la route du LSP au niveau du nœud d’entrée lorsqu’un événement d’échec de session BFD est détecté.

  • remove-route: supprime la route correspondant au LSP des tables de routage appropriées lorsqu’un événement d’échec de session BFD est détecté. Si le LSP est configuré avec ECMP et qu’une session BFD correspondant à un chemin d’accès tombe en panne, le routage est supprimé.

Pour configurer une action d’échec en cas d’échec de session BFD sur un LSP LDP, incluez l’option ou l’option de l’instruction remove-nexthopremove-routefailure-action :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Configuration de l’intervalle de retenue pour la session BFD

Vous pouvez spécifier la durée de la session BFD avant d’ajouter une route ou un saut suivant en configurant l’instruction holddown-interval au niveau de la hiérarchie ou au niveau de la [edit protocols ldp oam bfd-livenesss-detection][edit protocols ldp oam fec address bfd-livenesss-detection] hiérarchie. La spécification d’une durée de 0 seconde entraîne l’ajout de l’itinéraire ou du saut suivant dès que la session BFD est rétablie.

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Comprendre le reroutage rapide en multicast uniquement

Le reroutage rapide multicast uniquement (MoFRR) minimise la perte de paquets pour le trafic dans une arborescence de distribution multicast lorsque des défaillances de liaison se produisent, améliorant ainsi les protocoles de routage multicast tels que PIM (Protocol Independent Multicast) et multipoint LDP (Multipoint Label Distribution Protocol) sur les équipements qui prennent en charge ces fonctionnalités.

REMARQUE :

Sur les commutateurs, le MoFRR avec les chemins de commutation d’étiquettes MPLS et le LDP multipoint n’est pas pris en charge.

Pour les routeurs MX Series, MoFRR est pris en charge uniquement sur les routeurs MX Series avec des cartes de ligne MPC. Au préalable, vous devez configurer le routeur en network-services enhanced-ip mode et toutes les cartes de ligne du routeur doivent être des MPC.

Lorsque MoFRR est activé, les périphériques envoient des messages de jointure sur les chemins principaux et de secours en amont vers une source de multidiffusion. Les périphériques reçoivent des paquets de données à partir des chemins principal et de secours, et rejettent les paquets redondants en fonction de la priorité (pondérations attribuées aux chemins principal et de secours). Lorsqu’un équipement détecte une défaillance sur le chemin principal, il commence immédiatement à accepter des paquets provenant de l’interface secondaire (chemin de secours). Le basculement rapide améliore considérablement les temps de convergence en cas de défaillance de la liaison de chemin primaire.

L’une des applications du MoFRR est le streaming IPTV. Les flux IPTV sont multicast en tant que flux UDP, de sorte que les paquets perdus ne sont pas retransmis, ce qui entraîne une expérience utilisateur moins que satisfaisante. Le MoFRR peut améliorer la situation.

Vue d’ensemble du MoFRR

Avec le reroutage rapide sur les flux unicast, un périphérique de routage en amont préétablit des chemins de commutation d’étiquettes MPLS (LSP) ou précalcule un chemin de secours de reroutage rapide LFA (IP Loop Alternate) pour gérer la défaillance d’un segment dans le chemin en aval.

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

Dans une arborescence multicast, si l’équipement détecte une défaillance d’un composant réseau, il lui faut un certain temps pour effectuer une réparation réactive, ce qui entraîne une perte de trafic importante lors de la configuration d’un autre chemin. Le MoFRR réduit la perte de trafic dans une arborescence de distribution multicast en cas de défaillance d’un composant réseau. Avec MoFRR, l’un des périphériques de routage en aval configure un chemin alternatif vers la source pour recevoir un flux de sauvegarde en direct du même trafic multicast. Lorsqu’une défaillance se produit le long du flux primaire, le périphérique de routage MoFRR peut rapidement basculer vers le flux de secours.

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

MoFRR est pris en charge pour les familles de protocoles IPv4 et IPv6.

Figure 12 affiche deux chemins entre le périphérique de routage du récepteur multicast (également appelé périphérique PE (Egress Provider Edge)) et le périphérique de routage source multicast (également appelé périphérique PE d’entrée).

Figure 12 : Exemple de topologie MoFRRExemple de topologie MoFRR

Lorsque MoFRR est activé, le périphérique de routage de sortie (côté récepteur) configure deux arbres de multidiffusion, un chemin principal et un chemin de secours, vers la source de multidiffusion pour chacun (S,G). En d’autres termes, le périphérique de routage de sortie propage les mêmes messages de jointure (S,G) vers deux voisins en amont différents, créant ainsi deux arbres de multidiffusion.

L’un des arbres multicast passe par le plan 1 et l’autre par le plan 2, comme illustré à la .Figure 12 Pour chaque (S,G), le périphérique de routage de sortie 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 les routes alternatives sans boucle (LFA) unicast pour prendre en charge 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 de liaison sur une interface OSPF ou IS-IS, l’équipement crée un chemin LFA de secours vers le tronçon suivant principal pour toutes les routes de destination qui traversent l’interface protégée.

Junos OS implémente MoFRR dans le réseau IP pour IP MoFRR et au niveau du périphérique de routage de bordure d’étiquette MPLS (LER) pour le LDP MoFRR multipoint.

Le LDP multipoint MoFRR est utilisé au niveau de l’équipement de sortie d’un réseau MPLS, où les paquets sont transférés vers un réseau IP. Avec le LDP MoFRR multipoint, l’appareil établit deux chemins vers le périphérique de routage PE en amont pour recevoir deux flux de paquets MPLS au niveau du LER. L’appareil accepte l’un des flux (le flux principal) et l’autre (le flux de sauvegarde) est abandonné au niveau du LER. SI le chemin principal tombe en panne, l’appareil accepte le flux de sauvegarde à la place. La prise en charge de la signalisation intrabande est une condition préalable au MoFRR avec LDP multipoint (voir Présentation de la signalisation intrabande LDP multipoint pour les LSP point à multipoint).

Fonctionnalité PIM

Junos OS prend en charge MoFRR pour les jointures SPT (Shortest Path Tree) dans les PIM Source-Specific Multicast (SSM) et ASM (Any-Source Multicast). MoFRR est pris en charge pour les plages SSM et ASM. Pour activer MoFRR pour les jointures (*,G), incluez l’instruction de mofrr-asm-starg 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 pour les deux. (S,G) est toujours prioritaire sur (*,G).

Lorsque MoFRR est activé, un dispositif de routage PIM propage les messages de jointure sur deux interfaces RPF (Reverse-Path Forwarding) en amont pour recevoir le trafic multicast sur les deux liaisons pour la même demande de jointure. Le MoFRR privilégie deux chemins qui ne convergent pas vers le même périphérique de routage immédiat en amont. PIM installe les routes multicast appropriées avec les sauts suivants RPF en amont avec deux interfaces (pour les chemins principal et secondaire).

Lorsque le chemin principal tombe en panne, le chemin de sauvegarde est mis à niveau vers l’état principal et l’équipement transfère le trafic en conséquence. S’il existe d’autres chemins disponibles, MoFRR calcule un nouveau chemin de sauvegarde et met à jour ou installe le chemin de multicast approprié.

Vous pouvez activer MoFRR avec l’équilibrage de charge de jointure PIM (voir la join-load-balance automatic déclaration). Cependant, dans ce cas, la distribution des messages de jointure entre les liens peut ne pas être égale. Lorsqu’un nouveau lien ECMP est ajouté, les messages de jointure sur le chemin principal sont redistribués et équilibrés en charge. Les messages de jointure sur le chemin de sauvegarde peuvent toujours suivre le même chemin et ne pas être redistribués uniformément.

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

Lorsqu’un périphérique de routage PIM de sortie reçoit un message de jointure ou un rapport IGMP, il recherche une configuration MoFRR et procède comme suit :

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

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

  • En l’absence d’une stratégie, l’équipement recherche les chemins d’accès principal et secondaire (interfaces en amont) et procède comme suit :

    • Si les chemins principal et secondaire ne sont pas disponibles, PIM envoie un message de jointure en amont vers un voisin en amont (par exemple, le plan 2 dans Figure 12).

    • Si les chemins principal et secondaire sont disponibles : PIM envoie le message de jointure en amont vers deux des chemins voisins en amont disponibles. Junos OS configure les chemins multicast primaire et secondaire pour recevoir le trafic multicast (par exemple, plan 1 dans Figure 12).

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

    • En cas d’échec de cette vérification de stratégie, PIM envoie un message de jointure en amont vers un voisin en amont (par exemple, le plan 2 dans Figure 12).

    • Si cette vérification de stratégie réussit : l’appareil recherche les chemins d’accès principal et secondaire (interfaces en amont).

      • Si les chemins principal et secondaire ne sont pas disponibles, PIM envoie un message de jointure en amont vers un voisin en amont (par exemple, le plan 2 dans Figure 12).

      • Si les chemins principal et secondaire sont disponibles, PIM envoie le message de jointure en amont vers deux des voisins en amont disponibles. L’équipement configure les chemins de multidiffusion primaire et secondaire pour recevoir le trafic de multidiffusion (par exemple, le plan 1 dans 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 section 2.4.1.1. Déterminer son « LSR en amont » dans la RFC 6388, Extensions du protocole de distribution d’étiquettes pour les chemins commutés d’étiquettes point à multipoint et multipoint à multipoint.)

Pour le LDP multipoint avec MoFRR, l’équipement LDP multipoint sélectionne deux homologues en amont distincts et envoie deux étiquettes distinctes, une à chaque homologue en amont. L’appareil utilise le même algorithme que celui décrit dans la RFC 6388 pour sélectionner le chemin principal en amont. L’appareil utilise le même algorithme pour sélectionner le chemin d’accès amont de sauvegarde, mais exclut le LSR amont principal en tant que candidat. Les deux homologues en amont envoient deux flux de trafic MPLS au périphérique de routage de sortie. L’équipement sélectionne 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’appareil abandonne ce trafic. Lorsque le chemin amont principal tombe en panne, l’équipement commence à accepter le trafic du chemin de secours. Le périphérique LDP multipoint sélectionne les deux chemins en amont en fonction du tronçon 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, l’étiquette placée sur un paquet particulier représente la FEC à laquelle ce paquet est affecté. Dans MoFRR, deux routes sont placées dans la table mpls.0 pour chaque FEC : une route pour l’étiquette principale et l’autre route pour l’étiquette de sauvegarde.

S’il existe des liens parallèles vers le même équipement en amont immédiat, l’équipement considère que les deux liens parallèles sont les liens principaux. À 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 de sortie, mais qui a également un ou plusieurs LSR en aval directement connectés. Pour un nœud bud, le trafic du chemin amont principal est transféré vers un LSR en aval. En cas de défaillance du chemin amont principal, le trafic MPLS du chemin amont de sauvegarde est transféré vers le LSR en aval. Cela signifie que le prochain saut LSR en aval est ajouté aux deux routes MPLS avec le prochain saut de sortie.

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

Si vous avez activé la FEC point à multipoint LDP multipoint pour MoFRR, l’équipement tient compte des considérations suivantes pour sélectionner le chemin amont :

  • Les sessions LDP ciblées sont ignorées s’il existe une session LDP non ciblée. S’il existe une seule session LDP ciblée, la session LDP ciblée est sélectionnée, mais la FEC point à multipoint correspondante perd la capacité MoFRR, car aucune interface n’est associée à la session LDP ciblée.

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

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

Transfert de paquets

Dans le cas d’un PIM ou d’un LDP multipoint, l’équipement sélectionne le flux source de multidiffusion au niveau de l’interface d’entrée. Cela préserve la bande passante de la fabric et maximise les performances de transfert, car cela :

  • Évite d’envoyer des flux dupliqués sur la fabric

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

Pour 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 itinéraire. L’appareil vérifie l’interface sur laquelle chaque paquet arrive et ne transmet que ceux qui proviennent de l’interface principale. Si l’interface correspond à une interface de flux de sauvegarde, l’appareil abandonne les paquets. Si l’interface ne correspond pas à l’interface de flux principal ou de secours, l’équipement traite les paquets en tant qu’exceptions dans le plan de contrôle.

Figure 13 montre ce processus avec des exemples d’interfaces principale et secondaire pour les routeurs avec PIM. Figure 14 le montre de la même manière pour les commutateurs avec PIM.

Figure 13 : Recherche de route IP MoFRR dans le moteur de transfert de paquets sur les routeursRecherche de route IP MoFRR dans le moteur de transfert de paquets sur les routeurs
Figure 14 : Gestion des routes IP MoFRR dans le moteur de transfert de paquets sur les commutateursGestion des routes IP MoFRR dans le moteur de transfert de paquets sur les commutateurs

Pour MoFRR avec LDP multipoint sur les routeurs, l’appareil utilise plusieurs étiquettes MPLS pour contrôler la sélection de flux MoFRR. Chaque étiquette représente un itinéraire distinct, mais chacune fait référence à la même vérification de liste d’interfaces. L’appareil ne transfère que l’étiquette principale et supprime toutes les autres. Plusieurs interfaces peuvent recevoir des paquets en utilisant la même étiquette.

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

Figure 15 : Recherche de route MPLS MoFRR dans le moteur de transfert de paquetsRecherche de route MPLS MoFRR dans le moteur de transfert de paquets

Limites et mises en garde

Limitations et mises en garde du MoFRR sur les équipements de commutation et de routage

Le MoFRR présente les limitations et mises en garde suivantes concernant les dispositifs de routage et de commutation :

  • La détection des défaillances MoFRR est prise en charge pour une protection immédiate des liaisons du périphérique de routage sur lequel MoFRR est activé et non sur toutes les liaisons (de bout en bout) du chemin de trafic multicast.

  • MoFRR prend en charge le reroutage rapide sur deux chemins disjoints sélectionnés vers la source. Deux des voisins en amont sélectionnés ne peuvent pas se trouver sur la même interface, c’est-à-dire deux voisins en amont sur un segment LAN. Il en va de même si l’interface en amont est une interface tunnel multicast.

  • La détection du nombre maximal de chemins disjoints en amont de bout en bout n’est pas prise en charge. Le périphérique de routage côté récepteur (sortie) s’assure uniquement qu’il existe un périphérique amont disjoint (le saut précédent immédiat). PIM et LDP multipoint ne prennent pas en charge l’équivalent des objets de routage explicites (ERO). Par conséquent, la détection de chemin amont disjoint est limitée au contrôle du dispositif de saut immédiatement précédent. En raison de cette limitation, le chemin d’accès au périphérique en amont du saut précédent sélectionné comme serveur principal et de secours peut être partagé.

  • Vous pouvez constater une perte de trafic dans les scénarios suivants :

    • Un meilleur chemin amont devient disponible sur un équipement de sortie.

    • MoFRR est activé ou désactivé sur l’équipement de sortie lorsqu’un flux de trafic actif circule.

  • L’équilibrage de charge de jointure PIM pour les messages de jointure pour les chemins de sauvegarde n’est pas pris en charge.

  • Pour un groupe de multidiffusion G, MoFRR n’est pas autorisé pour les messages de jointure (S,G) et (*,G). Les messages de jointure (S,G) sont prioritaires sur (*,G).

  • MoFRR n’est pas pris en charge pour les flux de trafic multicast qui utilisent deux groupes multicast différents. Chaque combinaison (S,G) est traitée comme un flux de trafic multicast unique.

  • La plage PIM bidirectionnelle n’est pas prise en charge par MoFRR.

  • Le mode PIM dense n’est pas pris en charge avec MoFRR.

  • Les statistiques de multidiffusion pour le flux de trafic de sauvegarde ne sont pas gérées par PIM et ne sont donc pas disponibles dans la sortie opérationnelle des show commandes.

  • La surveillance des débits n’est pas prise en charge.

Limitations du MoFRR sur la commutation d’appareils avec PIM

Le MoFRR avec PIM présente les limitations suivantes pour les dispositifs de commutation :

  • MoFRR n’est pas pris en charge lorsque l’interface en amont est une interface IRB (Integrated Routing and Bridging), ce qui a un impact sur d’autres fonctionnalités de multidiffusion telles que la surveillance IGMPv3 (Internet Group Management Protocol).

  • La réplication des paquets et les recherches de multicast lors du transfert du trafic multicast peuvent entraîner la recirculation des paquets à travers les PFE plusieurs fois. Par conséquent, les valeurs affichées pour le nombre de paquets multicast à partir de la commande peuvent afficher des nombres plus élevés que prévu dans les show pfe statistics traffic champs de sortie tels que Input packets et Output packets. Vous remarquerez peut-être ce comportement plus fréquemment dans les scénarios MoFRR, car les flux principal et de secours en double augmentent le flux de trafic en général.

Limitations et mises en garde du MoFRR sur les périphériques de routage avec LDP multipoint

Le MoFRR présente les limitations et mises en garde suivantes sur les routeurs lorsqu’il est utilisé avec le LDP multipoint :

  • MoFRR ne s’applique pas au trafic LDP multipoint reçu sur un tunnel RSVP, car le tunnel RSVP n’est associé à aucune interface.

  • Le MoFRR mixte en amont n’est pas pris en charge. Il s’agit de la signalisation intrabande multipoint LDP PIM, dans laquelle un chemin en amont passe par le LDP multipoint et le second chemin en amont par PIM.

  • Les étiquettes LDP multipoints en tant qu’étiquettes internes ne sont pas prises en charge.

  • Si la source est accessible via plusieurs périphériques de routage Provider Edge (PE) entrants (côté source), le MoFRR LDP multipoint n’est pas pris en charge.

  • Les sessions LDP ciblées en amont ne sont pas sélectionnées comme périphérique en amont pour MoFRR.

  • La protection des liens LDP multipoints sur le chemin de sauvegarde n’est pas prise en charge, car il n’y a pas de prise en charge des étiquettes internes MoFRR.

Configuration du reroutage rapide multicast uniquement

Vous pouvez configurer le reroutage rapide multicast uniquement (MoFRR) pour minimiser la perte de paquets dans un réseau en cas de défaillance de liaison.

Lorsque le reroutage rapide est appliqué à des flux unicast, un routeur en amont préétablit des chemins de commutation d’étiquettes MPLS (LSP) ou précalcule un chemin de secours de reroutage rapide LFA (IP Loop Alternate) pour gérer la défaillance d’un segment dans le chemin en aval.

Dans le routage multicast, les graphes de distribution du trafic proviennent généralement du récepteur. Ceci est différent du routage unicast, qui établit généralement le chemin entre la source et le récepteur. Les protocoles capables d’établir des graphes de distribution multicast sont PIM (pour IP), Multipoint LDP (pour MPLS) et RSVP-TE (pour MPLS). Parmi ceux-ci, les récepteurs PIM et LDP multipoints initient la configuration du graphe de distribution, et donc :

  • Sur la gamme QFX, MoFRR est pris en charge dans les domaines PIM.

  • Sur les réseaux MX Series et SRX Series, MoFRR est pris en charge dans les domaines PIM et LDP multipoints.

Les étapes de configuration sont les mêmes pour l’activation de MoFRR for PIM sur tous les appareils prenant en charge cette fonctionnalité, sauf indication contraire. Les étapes de configuration qui ne s’appliquent pas au LDP MoFRR multipoint sont également indiquées.

(Pour les routeurs MX Series uniquement) MoFRR est pris en charge sur les routeurs MX Series avec des cartes de ligne MPC. Toutes les cartes de ligne du routeur doivent être des MPC.

Pour configurer MoFRR sur des routeurs ou des commutateurs :

  1. (Pour les routeurs MX Series et SRX Series uniquement) Réglez le routeur sur le mode IP amélioré.
  2. Activez MoFRR.
  3. (Facultatif) Configurez une stratégie de routage qui filtre un ensemble restreint de flux multicast à affecter par votre configuration MoFRR.

    Vous pouvez appliquer des filtres basés sur des adresses source ou de groupe.

    Par exemple :

  4. (Facultatif) Si vous avez configuré une stratégie de routage pour filtrer l’ensemble de groupes multicast affectés par votre configuration MoFRR, appliquez la stratégie de protection de flux MoFRR.

    Par exemple :

  5. (Facultatif) Dans un domaine PIM avec MoFRR, autorisez l’application de MoFRR aux jointures ASM (any-source multicast) (*,G).

    Ceci n’est pas pris en charge pour le LDP MoFRR multipoint.

  6. (Facultatif) Dans un domaine PIM avec MoFRR, n’autorisez qu’un RPF disjoint (un RPF sur un plan distinct) à être sélectionné comme chemin RPF de secours.

    Ceci n’est pas pris en charge pour le LDP MoFRR multipoint. Dans un domaine MoFRR LDP multipoint, la même étiquette est partagée entre des liens parallèles vers le même voisin en amont. Ce n’est pas le cas dans un domaine PIM, où chaque lien forme un voisin. L’instruction mofrr-disjoint-upstream-only ne permet pas de sélectionner un chemin RPF de sauvegarde si le chemin va au même voisin en amont que celui du chemin RPF principal. Cela permet de s’assurer que MoFRR n’est déclenché que sur une topologie qui a plusieurs voisins RPF en amont.

  7. (Facultatif) Dans un domaine PIM avec MoFRR, empêchez l’envoi de messages de jointure sur le chemin de sauvegarde, mais conservez toutes les autres fonctionnalités MoFRR.

    Ceci n’est pas pris en charge pour le LDP MoFRR multipoint.

  8. (Facultatif) Dans un domaine PIM avec MoFRR, autorisez la nouvelle sélection de chemin d’accès principal à être basée sur la sélection de passerelle unicast pour l’itinéraire unicast vers la source et à changer en cas de changement dans la sélection unicast, plutôt que de faire en sorte que le chemin de sauvegarde soit promu en tant que chemin principal. Cela permet de s’assurer que le saut RPF principal est toujours sur le meilleur chemin.

    Lorsque vous incluez l’instruction, il n’est mofrr-primary-selection-by-routing pas garanti que le chemin d’accès de sauvegarde soit promu en tant que nouveau chemin principal lorsque le chemin principal tombe en panne.

    Ceci n’est pas pris en charge pour le LDP MoFRR multipoint.

Exemple : Configuration du reroutage rapide multicast uniquement dans un domaine LDP multipoint

Cet exemple montre comment configurer le reroutage rapide multicast uniquement (MoFRR) pour minimiser la perte de paquets dans un réseau en cas de défaillance de liaison.

Le LDP multipoint MoFRR est utilisé au niveau du nœud de sortie d’un réseau MPLS, où les paquets sont transférés vers un réseau IP. Dans le cas du LDP MoFRR multipoint, les deux chemins vers le routeur PE (Provider Edge) en amont sont établis pour recevoir deux flux de paquets MPLS au niveau du routeur de périphérie d’étiquettes (LER). L’un des flux (le primaire) est accepté, et l’autre (le flux de secours) est abandonné au niveau du LER. Le flux de sauvegarde est accepté en cas de défaillance du chemin d’accès principal.

Conditions préalables

Aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise avant de configurer cet exemple.

Dans un domaine LDP multipoint, pour que MoFRR fonctionne, seul le routeur PE de sortie doit avoir MoFRR activé. Les autres routeurs n’ont pas besoin de prendre en charge MoFRR.

MoFRR est pris en charge sur les plates-formes MX Series avec des cartes de ligne MPC. Au préalable, le routeur doit être configuré en network-services enhanced-ip mode et toutes les cartes de ligne de la plate-forme doivent être des MPC.

Cet exemple nécessite Junos OS version 14.1 ou ultérieure sur le routeur PE de sortie.

Présentation

Dans cet exemple, le périphérique R3 est le routeur de périphérie de sortie. MoFRR n’est activé que sur cet appareil.

OSPF est utilisé pour la connectivité, bien que n’importe quel protocole IGP (Interior Gateway Protocol) ou routes statiques puissent être utilisés.

À des fins de test, des routeurs sont utilisés pour simuler la source et le récepteur. L’appareil R4 et l’appareil R8 sont configurés pour rejoindre statiquement le groupe souhaité à l’aide de la set protocols igmp interface interface-name static group group commande. Dans le cas où un hôte récepteur multicast réel n’est pas disponible, comme dans cet exemple, cette configuration IGMP statique est utile. Sur les récepteurs, pour leur faire écouter l’adresse du groupe multicast, cet exemple utilise set protocols sap listen group.

La configuration MoFRR inclut une option de stratégie qui n’est pas illustrée dans cet exemple, mais qui est expliquée séparément. L’option est configurée comme suit :

Topologie

Figure 16 montre l’exemple de réseau.

Figure 16 : MoFRR dans un domaine LDP multipointMoFRR dans un domaine LDP multipoint

Configuration rapide de l’interface de ligne de commande affiche la configuration de tous les périphériques dans Figure 16.

Cette section Configuration décrit les étapes à suivre sur l’appareil R3.

Configuration rapide de l’interface de ligne de commande

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie.

Appareil src1

Périphérique src2

Appareil R1

Appareil R2

Appareil R3

Appareil R4

Appareil R5

Appareil R6

Appareil R7

Appareil R8

Configuration

Procédure

Procédure étape par étape

L’exemple suivant nécessite que vous naviguiez à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande Junos OS.

Pour configurer l’appareil R3 :

  1. Activez le mode IP amélioré.

  2. Configurez les interfaces de l’appareil.

  3. Configurez le numéro du système autonome (AS).

  4. Configurez les stratégies de routage.

  5. Configurez PIM.

  6. Configurez LDP.

  7. Configurez un IGP ou des routes statiques.

  8. Configurez le BGP interne.

  9. Configurez MPLS et, éventuellement, RSVP.

  10. Activez MoFRR.

Résultats

À partir du mode de configuration, confirmez votre configuration en saisissant les commandes show chassis, show interfaces, show protocols, show policy-options et show routing-options. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification des classes d’équivalence de transfert point à multipoint LDP

But

Assurez-vous que le MoFRR est activé et déterminez quelles étiquettes sont utilisées.

Action
Sens

La sortie indique que MoFRR est activé et que les étiquettes 301568 et 301600 sont utilisées pour les deux LSP point à multipoint LDP multipoints.

Examen de l’information sur l’étiquette

But

Assurez-vous que le périphérique de sortie dispose de deux interfaces en amont pour la jonction du groupe de multidiffusion.

Action
Sens

La sortie affiche les chemins d’accès principaux en amont et les chemins d’accès de secours en amont. Il montre également les sauts suivants du RPF.

Vérification des routes de multidiffusion

But

Examinez le multicast IP table de transfert pour vous assurer qu’il existe une liste d’interfaces RPF en amont, avec une interface principale et une interface de secours.

Action
Sens

La sortie affiche les sessions primaires et de secours, ainsi que les sauts suivants RPF.

Vérification des statistiques de trafic point à multipoint LDP

But

Assurez-vous que les statistiques principales et de sauvegarde sont répertoriées.

Action
Sens

La sortie affiche à la fois les routes primaires et secondaires avec les étiquettes.

Exemple : Configuration de LDP en aval à la demande

Cet exemple montre comment configurer LDP en aval à la demande. LDP est généralement configuré à l’aide du mode d’annonce non sollicitée en aval, ce qui signifie que les annonces d’étiquettes pour toutes les routes sont reçues de tous les homologues LDP. Comme les fournisseurs de services intègrent les réseaux d’accès et d’agrégation dans un seul domaine MPLS, un processus LDP en aval à la demande est nécessaire pour distribuer les liaisons entre les réseaux d’accès et d’agrégation et réduire les exigences de traitement pour le plan de contrôle.

Les nœuds en aval peuvent potentiellement recevoir des dizaines de milliers de liaisons d’étiquettes de la part des nœuds d’agrégation en amont. Au lieu d’apprendre et de stocker toutes les liaisons d’étiquettes pour toutes les adresses de bouclage possibles dans l’ensemble du réseau MPLS, le nud d’agrégation en aval peut être configuré à l’aide de LDP en aval à la demande pour demander uniquement les liaisons d’étiquettes pour les FEC correspondant aux adresses de bouclage des nuds de sortie sur lesquels des services sont configurés.

Conditions préalables

Cet exemple utilise les composants matériels et logiciels suivants :

  • Routeur M Series

  • Junos OS 12.2

Présentation

Vous pouvez activer l’annonce d’étiquette LDP en aval à la demande pour une session LDP en incluant l’instruction en aval à la demande au niveau de la [edit protocols ldp session] hiérarchie. Si vous avez configuré la demande en aval à la demande, le routeur Juniper Networks annonce la demande en aval à la demande à ses routeurs homologues. Pour qu’une session à la demande en aval soit établie entre deux routeurs, les deux doivent annoncer le mode à la demande en aval lors de l’établissement d’une session LDP. Si un routeur annonce le mode non sollicité en aval et l’autre le mode en aval à la demande, le mode non sollicité en aval est utilisé.

Configuration

Configuration de LDP en aval à la demande

Procédure étape par étape

Pour configurer une stratégie LDP en aval à la demande, puis configurer cette stratégie et activer LDP en aval à la demande sur la session LDP :

  1. Configurez la stratégie à la demande en aval (DOD-Request-Loopbacks dans cet exemple).

    En vertu de cette stratégie, le routeur transfère les messages de demande d’étiquette uniquement aux FEC qui correspondent à la DOD-Request-Loopbacks stratégie.

  2. Spécifiez la stratégie DOD-Request-Loopbacks à l’aide de l’instruction au niveau de dod-request-policy la [edit protocols ldp] hiérarchie.

    La stratégie spécifiée avec l’instruction est utilisée pour identifier les préfixes pour envoyer des messages de demande d’étiquette dod-request-policy . Cette stratégie est similaire à une stratégie de sortie ou à une stratégie d’importation. Lors du traitement des routes à partir de la table de routage inet.0, le logiciel Junos OS recherche les routes correspondant à la DOD-Request-Loopbacks stratégie (dans cet exemple). Si l’itinéraire correspond à la stratégie et que la session LDP est négociée avec le mode d’annonce du ministère de la Défense, les messages de demande d’étiquette sont envoyés à la session LDP en aval correspondante.

  3. Incluez l’instruction downstream-on-demand dans la configuration de la session LDP pour activer le mode de distribution à la demande en aval.

Distribution des routes LDP en aval à la demande dans des BGP étiquetés

Procédure étape par étape

Pour distribuer des routes LDP en aval à la demande dans des BGP étiquetés, utilisez une stratégie d’exportation BGP.

  1. Configurez la stratégie de routage LDP (redistribute_ldp dans cet exemple).

  2. Incluez la stratégie redistribute_ldp de routage LDP dans la configuration BGP (dans le cadre de la configuration ebgp-to-abr du groupe BGP dans cet exemple).

    BGP transfère les routes LDP en fonction de la redistribute_ldp stratégie vers le routeur PE distant

Procédure étape par étape

Pour restreindre la propagation d’étiquettes à d’autres routeurs configurés en mode non sollicité en aval (au lieu d’être en aval à la demande), configurez les stratégies suivantes :

  1. Configurez la stratégie pour qu’elle accepte les dod-routes routes de LDP.

  2. Configurez la do-not-propagate-du-sessions stratégie pour qu’elle ne transfère pas les routes aux voisins 10.1.1.1, 10.2.2.2, et 10.3.3.3.

  3. Configurez la stratégie pour empêcher le transfert des routes examinées par la stratégie vers les routeurs voisins définis dans la filter-dod-on-du-sessionsdod-routesdo-not-propagate-du-sessions stratégie.

  4. Spécifiez la filter-dod-routes-on-du-sesssion stratégie en tant que stratégie d’exportation pour BGP group ebgp-to-abr.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les commandes show policy-options et show protocols ldp . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Vérification

Vérification du mode d’annonce de l’étiquette

But

Vérifiez que la configuration fonctionne correctement.

Utilisez la commande pour vérifier l’état du mode d’annonce d’étiquette pour la show ldp session session LDP.

Action

Exécutez les show ldp session commandes et show ldp session detail :

  • La sortie de commande suivante pour la commande indique que le (mode d’annonce d’étiquette Adv. Mode ) est (ce qui signifie que la session LDP en aval à la show ldp session demande est DOD opérationnelle) :

  • La sortie de commande suivante pour la commande indique Downstream unsolicitedque est , la valeur par défaut (ce qui signifie que la valeur en aval à la demande n’est Local Label Advertisement mode pas configurée sur la show ldp session detail session locale). À l’inverse, les Remote Label Advertisement mode et les Negotiated Label Advertisement mode deux indiquent que Downstream on demand est configuré sur la session distante

Configuration de la prise en charge IPv6 native LDP

LDP est pris en charge dans un réseau IPv6 uniquement et dans un réseau IPv6 ou IPv4 à double pile, comme décrit dans la RFC 7552. Configurez la famille d’adresses comme IPv4 ou IPv6 ou les deux, et la préférence de transport pour qu’elle inet soit soit IPv4 ou inet6IPv6. L’instruction dual-transport permet à Junos OS LDP d’établir la connexion TCP sur IPv4 avec des voisins IPv4 et sur IPv6 avec des voisins IPv6 en tant que LSR à pile unique. Les inet-lsr-id ID et sont les deux ID LSR qui doivent être configurés pour établir une session LDP sur un transport TCP IPv4 et inet6-lsr-id IPv6. Ces deux ID doivent être différents de zéro et doivent être configurés avec des valeurs différentes.

Avant de configurer IPv6 en tant que double pile, assurez-vous de configurer les protocoles de routage et de signalisation.

Pour configurer la prise en charge IPv6 native de LDP, vous devez procéder comme suit :

  1. Activez la désagrégation de la classe d’équivalence de transfert (FEC) afin d’utiliser différentes étiquettes pour différentes familles d’adresses.
  2. Configurez les familles d’adresses LDP.
  3. Configurez l’instruction transport-preference pour sélectionner le transport préféré pour la connexion TCP lorsque IPv4 et IPv6 sont activés. Par défaut, IPv6 est utilisé comme transport TCP pour l’établissement d’une connexion LDP.
  4. (Facultatif) Configurez le double transport pour permettre à LDP d’établir une session IPv4 distincte avec un voisin IPv4 et une session IPv6 avec un voisin IPv6. Configurez-le inet-lsr-id en tant qu’ID LSR pour IPv4 et inet6-lsr-id en tant qu’ID LSR pour IPv6.

    Par exemple, configurez inet-lsr-id en tant que 10.255.0.1 et inet6-lsr-id en tant que 10.1.1.1.

Exemple : Configuration de la prise en charge IPv6 native LDP

Cet exemple montre comment autoriser le protocole LDP (Label Distribution Protocol) de Junos OS à établir la connexion TCP sur IPv4 avec des voisins IPv4 et sur IPv6 avec des voisins IPv6 en tant que LSR à pile unique. Cela permet d’éviter la tunnelisation d’IPv6 sur un cœur MPLS IPv4 avec des chemins de commutation d’étiquettes (LSP) MPLS signalés par IPv4.

Conditions préalables

Cet exemple utilise les composants matériels et logiciels suivants :

  • Deux routeurs MX Series

  • Junos OS version 16.1 ou ultérieure s’exécute sur tous les équipements

Avant de configurer IPv6 en tant que double pile, assurez-vous de configurer les protocoles de routage et de signalisation.

Présentation

Le protocole LDP est pris en charge dans un réseau IPv6 uniquement et dans un réseau IPv6 ou IPv4 à double pile, comme décrit dans le document RFC 7552. Configurez la famille d’adresses comme inet pour IPv4 ou inet6 pour IPv6. Par défaut, IPv6 est utilisé comme transport TCP pour la session LDP avec ses homologues lorsque IPv4 et IPv6 sont activés. L’instruction dual-transport permet à Junos LDP d’établir la connexion TCP sur IPv4 avec des voisins IPv4, et sur IPv6 avec des voisins IPv6 en tant que LSR à pile unique. Les inet-lsr-id et inet6-lsr-id sont les deux ID LSR qui doivent être configurés pour établir une session LDP sur un transport TCP IPv4 et IPv6. Ces deux ID doivent être différents de zéro et doivent être configurés avec des valeurs différentes.

Topologie

Figure 17 affiche le LDP IPv6 configuré en tant que double pile sur les appareils R1 et R2.

Figure 17 : Exemple de prise en charge IPv6 native de LDPExemple de prise en charge IPv6 native de LDP

Configuration

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.

R1

R2

Configuration de R1

Procédure étape par étape

L’exemple suivant nécessite que vous naviguiez à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section « Using the CLI Editor in Configuration Mode » du Guide de l’utilisateur de l’interface de ligne de commande Junos OS.

Pour configurer l’appareil R1 :

  1. Configurez les interfaces.

  2. Attribuez une adresse de bouclage à l’appareil.

  3. Configurez les interfaces IS-IS.

  4. Configurez MPLS pour utiliser les interfaces LDP sur l’équipement.

  5. Activez la désagrégation de la classe d’équivalence de transfert (FEC) afin d’utiliser différentes étiquettes pour différentes familles d’adresses.

  6. Configurez les familles d’adresses LDP.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les commandes show interfaces et show protocols . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Configurez la préférence de transport pour sélectionner le transport préféré

Configuration rapide de l’interface de ligne de commande
Procédure étape par étape

Vous pouvez configurer l’instruction transport-preference pour sélectionner le transport préféré pour une connexion TCP lorsque IPv4 et IPv6 sont activés. Par défaut, IPv6 est utilisé comme transport TCP pour l’établissement d’une connexion LDP.

  • (Facultatif) Configurez la préférence de transport pour une connexion LDP.

Procédure étape par étape
Résultats

À partir du mode configuration, confirmez votre configuration en entrant la show protocols commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Configurer le double transport pour établir des sessions distinctes pour IPv4 avec un voisin IPv4 et IPv6 avec un voisin IPv6

Procédure étape par étape

Vous pouvez configurer l’instruction pour permettre à LDP d’établir dual-transport une session IPv4 distincte avec un voisin IPv4 et une session IPv6 avec un voisin IPv6. Cela nécessite la configuration de inet-lsr-id en tant qu’ID LSR pour IPv4 et inet6-lsr-id en tant qu’ID LSR pour IPv6.

  • (Facultatif) Configurez le double transport pour permettre à LDP d’établir la connexion TCP sur IPv4 avec des voisins IPv4 et sur IPv6 avec des voisins IPv6 en tant que LSR à pile unique.

Résultats

À partir du mode configuration, confirmez votre configuration en entrant la show protocols commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification des entrées de route dans la table mpls.0
But

Affiche les informations de la table de routage mpls.0.

Action

Sur le périphérique R1, à partir du mode opérationnel, exécutez la commande pour afficher les informations de la show route table mpls.0 table de routage mpls.0.

Sens

La sortie affiche les informations de la table de routage mpls.0.

Vérification des entrées de route dans le tableau inet.3
But

Affichez les informations de la table de routage inet.3.

Action

Sur le périphérique R1, à partir du mode opérationnel, exécutez la commande pour afficher les show route table inet.3 informations de la table de routage inet.3.

Sens

La sortie affiche les informations de la table de routage inet.3.

Vérification des entrées de route dans la table inet6.3
But

Affiche les informations de la table de routage inet6.3.

Action

Sur le périphérique R1, à partir du mode opérationnel, exécutez la commande pour afficher les show route table inet6.3 informations de la table de routage inet6.3.

Sens

La sortie affiche les informations de la table de routage inet6.3.

Vérification de la base de données LDP
But

Affichez les informations de la base de données LDP.

Action

Sur l’appareil R1, à partir du mode opérationnel, exécutez la commande pour afficher les informations de la show ldp database base de données LDP.

Sens

La sortie affiche les entrées de la base de données LDP.

Vérification des informations de voisinage LDP
But

Affichez les informations de voisinage LDP.

Action

Sur le périphérique R1, à partir du mode opérationnel, exécutez les show ldp neighbor commandes et show ldp neighbor extensive pour afficher les informations de voisinage LDP.

Sens

La sortie affiche les informations de voisinage LDP des adresses IPv4 et IPv6.

Vérification des informations de session LDP
But

Affichez les informations de la session LDP.

Action

Sur l’appareil R1, à partir du mode opérationnel, exécutez les show ldp session commandes et show ldp session extensive pour afficher les informations de session LDP.

Sens

La sortie affiche des informations sur la session LDP en utilisant IPv6 comme transport TCP.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification des informations de voisinage LDP
But

Affichez les informations de voisinage LDP.

Action

Sur le périphérique R1, à partir du mode opérationnel, exécutez la commande pour afficher les show ldp neighbor extensive informations de voisinage LDP.

Sens

La sortie affiche des informations de voisinage LDP pour les adresses IPv4 et IPv6.

Vérification des informations de session LDP
But

Affichez les informations de la session LDP.

Action

Sur le périphérique R1, à partir du mode opérationnel, exécutez la show ldp session extensive commande pour afficher les informations de session LDP.

Sens

La sortie affiche des informations sur la session LDP en utilisant IPv6 comme transport TCP.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification des informations de voisinage LDP
But

Affichez les informations de voisinage LDP.

Action

Sur le périphérique R1, à partir du mode opérationnel, exécutez la commande pour afficher les show ldp neighbor extensive informations de voisinage LDP.

Sens

La sortie affiche des informations de voisinage LDP pour les adresses IPv4 et IPv6.

Vérification des informations de session LDP
But

Affichez les informations de la session LDP.

Action

Sur le périphérique R1, à partir du mode opérationnel, exécutez la commande pour afficher les show ldp session extensive informations de voisinage LDP.

Exemple : Configuration de la signalisation intrabande LDP multipoint pour les LSP point à multipoint

Comprendre la signalisation intrabande LDP multipoint pour les LSP point à multipoint

Le protocole M-LDP (Multipoint Label Distribution Protocol) pour les chemins de commutation d’étiquettes (LSP) point à multipoint avec signalisation intrabande est utile dans un déploiement avec un réseau dorsal IP/MPLS existant, dans lequel vous devez transporter du trafic multicast, pour l’IPTV par exemple.

Pendant des années, la solution la plus largement utilisée pour acheminer le trafic multicast a consisté à utiliser le multicast IP natif dans le noyau du fournisseur de services avec un tunneling IP multipoint pour isoler le trafic client. Un protocole de routage multicast, généralement PIM (Protocol Independent Multicast), est déployé pour configurer les chemins de transfert. Le routage multicast IP est utilisé pour le transfert, en utilisant la signalisation PIM dans le noyau. Pour que ce modèle fonctionne, le réseau central doit être compatible avec la multidiffusion. Cela permet des déploiements efficaces et stables, même dans des scénarios de systèmes interautonomes (AS).

Cependant, dans un réseau IP/MPLS existant, le déploiement de PIM n’est peut-être pas le premier choix. Certains fournisseurs de services souhaitent remplacer les tunnels IP par l’encapsulation d’étiquettes MPLS. Le passage à la commutation d’étiquettes MPLS est motivé par l’exploitation des fonctionnalités d’aspects techniques du trafic MPLS et de protection et pour réduire la surcharge du trafic de contrôle dans le cur du fournisseur.

Pour ce faire, les fournisseurs de services souhaitent tirer parti de l’extension des déploiements existants pour permettre le passage du trafic multicast. Les extensions multicast existantes pour IP/MPLS sont des extensions point à multipoint pour RSVP-TE et des extensions point à multipoint et multipoint à multipoint pour LDP. Ces scénarios de déploiement sont décrits dans la RFC 6826, Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths. Cette vue d’ensemble des fonctionnalités est limitée aux extensions point à multipoint pour LDP.

Comment fonctionne M-LDP ?

Liaisons d’étiquettes dans la signalisation M-LDP

L’extension multipoint de LDP utilise des éléments de classe d’équivalence de transfert (FEC) point à multipoint et multipoint à multipoint (définis dans la RFC 5036, spécification LDP) ainsi que des annonces de capacité, un mappage d’étiquettes et des procédures de signalisation. Les éléments FEC incluent l’idée de la racine LSP, qui est une adresse IP, et une valeur « opaque », qui est un sélecteur qui regroupe les nœuds leaf partageant la même valeur opaque. La valeur opaque est transparente pour les nœuds intermédiaires, mais a une signification pour la racine LSP. Chaque nœud LDP annonce sa liaison d’étiquette entrante locale au nœud LDP en amont sur le chemin le plus court vers l’adresse IP racine trouvée dans la FEC. Le nœud amont recevant les liaisons d’étiquettes crée ses propres interfaces d’étiquettes locales et sortantes. Ce processus d’attribution d’étiquettes peut entraîner une réplication des paquets, s’il existe plusieurs branches sortantes. Comme illustré à Figure 18la , un nœud LDP fusionne les liaisons d’étiquettes pour la même valeur opaque s’il trouve des nœuds en aval partageant le même nœud en amont. Cela permet de construire efficacement des LSP point à multipoint et de conserver l’étiquette.

Figure 18 : Liaisons d’étiquettes dans la signalisation M-LDPLiaisons d’étiquettes dans la signalisation M-LDP
M-LDP dans un réseau central MPLS sans PIM

Figure 19 montre un scénario de déploiement réduit. Deux domaines PIM distincts sont interconnectés par un site central sans PIM. Les routeurs de bordure de ce site central prennent en charge PIM sur les interfaces de bordure. De plus, ces routeurs de bordure collectent et distribuent les informations de routage des sites adjacents vers le réseau central. Les routeurs de périphérie du site C exécutent BGP pour la découverte des nuds racines. Les routes IGP (Interior Gateway Protocol) ne peuvent pas être utilisées pour la découverte d’entrée, car dans la plupart des cas, le prochain saut de transfert fourni par l’IGP ne fournit pas d’informations sur le périphérique d’entrée vers la source. La signalisation intrabande M-LDP a un mappage un-à-un entre le LSP point à multipoint et le flux (S,G). Avec la signalisation intrabande, les messages PIM sont directement traduits en liaisons M-LDP FEC. En revanche, la signalisation hors bande est basée sur une configuration manuelle. L’une des applications de la signalisation intrabande M-LDP consiste à transporter le trafic multicast IPTV dans un réseau dorsal MPLS.

Figure 19 : Exemple de topologie M-LDP dans un cœur MPLS sans PIMExemple de topologie M-LDP dans un cœur MPLS sans PIM
Configuration

L’instruction de configuration mldp-inband-signalling sur le routeur de périphérie d’étiquettes (LER) permet à PIM d’utiliser la signalisation intrabande M-LDP pour les voisins en amont lorsque le LER ne détecte pas de voisin PIM en amont. La configuration statique de la racine du LSP MPLS est incluse dans la configuration PIM, à l’aide d’une stratégie. Cela est nécessaire lorsque l’IBGP n’est pas disponible dans le site principal ou pour remplacer la détection racine du LSP basé sur l’IBGP.

Par exemple :

M-LDP dans un réseau central MPLS compatible PIM

À partir de Junos OS version 14.1, afin de migrer les services IPTV existants du multicast IP natif vers le multicast MPLS, vous devez effectuer une transition en douceur de PIM vers les LSP point à multipoint M-LDP avec un minimum de panne. Figure 20 montre une topologie M-LDP similaire à Figure 19, mais avec un scénario différent. Le cœur est activé avec PIM, avec une source diffusant toutes les chaînes IPTV. Les chaînes de télévision sont envoyées sous forme de flux ASM, chaque chaîne étant identifiée par son adresse de groupe. Auparavant, ces canaux étaient diffusés sur le réseau central sous forme de flux IP et signalés à l’aide de PIM.

Figure 20 : Exemple de topologie M-LDP dans un réseau central MPLS compatible PIMExemple de topologie M-LDP dans un réseau central MPLS compatible PIM

En configurant le mldp-inband-signaling dans ce scénario, la signalisation M-LDP n’est lancée que lorsqu’il n’y a pas de voisin PIM vers la source. Toutefois, étant donné qu’il existe toujours un voisin PIM vers la source, sauf si PIM est désactivé sur les interfaces en amont du PE de sortie, PIM est prioritaire sur M-LDP et M-LDP ne prend pas effet.

Configuration

Pour migrer progressivement canal par canal vers un cœur MMPLS M-LDP avec quelques flux utilisant M-LDP en amont et d’autres flux utilisant PIM en amont, incluez l’instruction de configuration ainsi que les selected-mldp-egress filtres basés sur des groupes dans le filtre de stratégie pour la signalisation intrabande M-LDP.

REMARQUE :

Le filtre de stratégie de signalisation intrabande M-LDP peut inclure l’instruction ou l’instruction source-address-filterroute-filter , ou une combinaison des deux.

Par exemple :

REMARQUE :

Voici quelques-unes des limitations de la configuration ci-dessus :

  • L’instruction selected-mldp-egress ne doit être configurée que sur le LER. La configuration de l’instruction selected-mldp-egress sur des routeurs PIM sans sortie peut entraîner des échecs de configuration de chemin.

  • Lorsque des changements de stratégie sont apportés pour faire basculer le trafic de PIM en amont vers M-LDP en amont et vice-versa, on peut s’attendre à une perte de paquets car un mécanisme de break-and-make est exécuté au niveau du plan de contrôle.

Terminologie

Les termes suivants sont importants pour comprendre la signalisation intrabande M-LDP pour le trafic multidiffusion.

Point-to-point LSP

Un LSP qui a un routeur à commutation d’étiquettes (LSR) d’entrée et un LSR de sortie.
Multipoint LSP

Il s’agit soit d’un LSP point-à-multipoint, soit d’un LSP multipoint-multipoint.
Point-to-multipoint LSP

Un LSP qui a un LSR d’entrée et un ou plusieurs LSR de sortie.
Multipoint-to-point LSP

Un LSP qui a un ou plusieurs LSR d’entrée et un LSR de sortie unique.
Multipoint-to-multipoint LSP

LSP qui connecte un ensemble de nuds, de sorte que le trafic envoyé par n’importe quel nud du LSP soit remis à tous les autres.

Ingress LSR

Un LSR d’entrée pour un LSP particulier est un LSR qui peut envoyer un paquet de données le long du LSP. Les LSP multipoint à multipoint peuvent avoir plusieurs LSR d’entrée. Les LSP point à multipoint n’en ont qu’un, et ce nœud est souvent appelé nœud racine.
Egress LSR

Un LSR de sortie pour un LSP particulier est un LSR qui peut supprimer un paquet de données de ce LSP pour un traitement ultérieur. Les LSP point à point et multipoint à point n’ont qu’un seul nœud de sortie. Les LSP point à multipoint et multipoint à multipoint peuvent avoir plusieurs nœuds de sortie.
Transit LSR

Un LSR qui a une accessibilité à la racine du LSP multipoint par le biais d’un LSR en amont directement connecté et d’un ou plusieurs LSR en aval directement connectés.

Bud LSR

Un LSR qui est un LSR de sortie, mais qui a également un ou plusieurs LSR en aval directement connectés.
Leaf node

Il s’agit soit d’un LSR de sortie, soit d’un LSR bud dans le contexte d’un LSP point à multipoint. Dans le contexte d’un LSP multipoint à multipoint, un LSR est à la fois un LSP d’entrée et de sortie pour le même LSP multipoint à multipoint et peut également être un LSR bourgeon.

Traduction des jointures entrantes et gestion des pseudo-interfaces

Au niveau du LER d’entrée, LDP informe le PIM des messages (S,G) reçus via la signalisation intrabande. Le PIM associe chaque message (S,G) à une pseudo-interface. Par la suite, un message de jointure SPT (shortest-path-tree) est initié vers la source. Le PIM considère cela comme un nouveau type de récepteur local. Lorsque le LSP est démantelé, PIM supprime ce récepteur local en fonction de la notification de LDP.

Épissure d’entrée

LDP fournit au PIM un saut suivant à associer à chaque entrée (S,G). PIM installe une route de multidiffusion PIM (S,G) avec le saut suivant LDP et d’autres récepteurs PIM. Le saut suivant est un saut suivant composite de récepteurs locaux + la liste des voisins PIM en aval + un saut suivant de sous-niveau pour le tunnel LDP.

Transfert de chemin inverse

Le calcul RPF (reverse-path-forwarding) de PIM est effectué au niveau du nœud de sortie.

PIM effectue une signalisation M-LDP intrabande lorsque toutes les conditions suivantes sont remplies :

  • Il n’y a pas de voisins PIM vers la source.

  • L’instruction de signalisation intrabande M-LDP est configurée.

  • Le saut suivant est appris via BGP ou est présent dans le mappage statique (spécifié dans une stratégie de signalisation intrabande M-LDP).

Dans le cas contraire, si la détection racine du LSP échoue, PIM conserve l’entrée (S,G) avec un état RPF non résolu.

PIM RPF enregistre cette adresse source chaque fois que les informations de routage unicast changent. Par conséquent, si l’itinéraire vers la source change, le recalcul RPF se répète. Les sauts suivants du protocole BGP vers la source sont également surveillés pour détecter les changements dans la racine LSP. De telles modifications peuvent entraîner des perturbations du trafic pendant de courtes durées.

Détection racine LSP

Si l’opération RPF détecte la nécessité d’une signalisation intrabande M-LDP en amont, la racine LSP (entrée) est détectée. Cette racine est un paramètre pour la signalisation LDP LSP.

Le noeud racine est détecté comme suit :

  1. Si la configuration statique existante spécifie l’adresse source, la racine est prise comme donnée dans la configuration.

  2. Une recherche est effectuée dans la table de routage unicast. Si l’adresse source est trouvée, le prochain saut de protocole vers la source est utilisé comme racine LSP.

    Avant Junos OS version 16.1, le LSP POINT À MULTIPOINT M-LDP était signalé d’une sortie à l’entrée à l’aide de l’adresse racine du LSR entrant. Cette adresse racine n’est accessible que par IGP, ce qui limite le LSP POINT À MULTIPOINT M-LDP à un seul système autonome. Si l’adresse racine n’est pas accessible via un IGP, mais accessible via BGP, et si cette route BGP est résolue récursivement sur un LSP MPLS, le LSP point à multipoint n’est pas signalé plus loin de ce point vers l’adresse racine LSR entrante.

    Il est nécessaire que ces LSP point à multipoint non segmentés soient signalés sur plusieurs systèmes autonomes, ce qui peut être utilisé pour les applications suivantes :

    • MVPN inter-AS avec des LSP point à multipoint non segmentés.

    • Signalisation intrabande M-LDP INTER-AS entre des réseaux clients connectés par un réseau central MPLS.

    • Signalisation intrabande MVPN ou M-LDP inter-zone avec LSP point à multipoint non segmentés (MPLS multicast transparent).

    À partir de Junos OS version 16.1, M-LDP peut signaler des LSP point à multipoint au niveau ASBR ou en transit ou en sortie lorsque l’adresse racine est une route BGP qui est ensuite résolue de manière récursive sur un LSP MPLS.

Traduction des jointures sortantes et gestion des pseudo-interfaces

Au niveau du LER de sortie, PIM informe LDP du message (S,G) à signaler avec la racine LSP. PIM crée une pseudo-interface en tant qu’interface en amont pour ce message (S,G). Lorsqu’un message d’élagage (S,G) est reçu, cette association est supprimée.

Épissure de sortie

Au niveau du noeud de sortie du réseau central, où le message de jonction (S,G) du site en aval est reçu, ce message de jonction est traduit en paramètres de signalisation intrabande M-LDP et LDP en est informé. En outre, le démontage du LSP se produit lorsque l’entrée (S,G) est perdue, lorsque la racine du LSP change ou lorsque l’entrée (S,G) est accessible sur un voisin PIM.

Fonctionnalités prises en charge

Pour la signalisation intrabande M-LDP, Junos OS prend en charge les fonctionnalités suivantes :

  • Épissage de sortie du PIM next hop avec la route LDP

  • Épissage d’entrée de la route PIM avec le saut suivant LDP

  • Conversion des messages de jointure PIM en paramètres de configuration LSP point à multipoint LDP

  • Traduction des paramètres LSP intrabande M-LDP pour configurer les messages de jointure PIM

  • Détection de la racine du LSP basée sur le protocole BGP à configuration statique et basée sur le protocole BGP

  • États PIM (S,G) dans les plages PIM source-specific multicast (SSM) et anysource multicsast (ASM)

  • Instructions de configuration sur les LER entrants et sortants pour leur permettre d’agir en tant que routeurs de périphérie

  • Messages de jointure IGMP sur les LER

  • Transporter l’adresse source et l’adresse de groupe IPv6 sous forme d’informations opaques vers un nud racine IPv4

  • Configuration statique pour mapper une adresse IPv6 (S,G) à une adresse racine IPv4

Fonctionnalités non prises en charge

Pour la signalisation intrabande M-LDP, Junos OS ne prend pas en charge les fonctionnalités suivantes :

  • Prise en charge complète de PIM ASM

  • La mpls lsp point-to-multipoint ping commande avec une option (S,G)

  • NSR (NonStop active Routing )

  • Make-before-break (MBB) pour PIM

  • Adresses racine des LSP IPv6 (LDP ne prend pas en charge les LSP IPv6.)

  • Relation de voisinage entre des haut-parleurs PIM qui ne sont pas directement connectés

  • * Redémarrage progressif

  • PIM Dense Mode

  • Mode PIM bidirectionnel

Fonctionnalité LDP

Les informations PIM (S,G) sont portées sous forme de codages M-LDP opaques type-longueur-valeur (TLV). L’élément FEC point-à-multipoint est constitué de l’adresse du nœud racine. Dans le cas des VPN multicast nouvelle génération (NGEN MVPN), le LSP point à multipoint est identifié par l’adresse du nœud racine et l’ID LSP.

Fonctionnalité Egress LER

Sur le LER de sortie, PIM déclenche LDP avec les informations suivantes pour créer un LSP point à multipoint :

  • Nœud racine

  • (S,G)

  • Saut suivant

PIM recherche le nœud racine en fonction de la source de l’arborescence de multidiffusion. Si l’adresse racine est configurée pour cette entrée (S,G), l’adresse configurée est utilisée comme racine LSP point à multipoint. Sinon, la table de routage est utilisée pour rechercher l’itinéraire vers la source. Si le chemin vers la source de l’arborescence de multidiffusion est un itinéraire BGP appris, PIM récupère l’adresse du tronçon suivant BGP et l’utilise comme nœud racine pour le LSP point à multipoint.

LDP recherche le noeud amont en fonction du noeud racine, alloue une étiquette et envoie le mappage d’étiquettes au noeud amont. LDP n’utilise pas l’avant-dernier saut popping (PHP) pour la signalisation M-LDP intrabande.

Si les adresses racine de la source de l’arborescence de multidiffusion changent, PIM supprime le LSP point à multipoint et déclenche la création d’un LSP point à multipoint par LDP. Lorsque cela se produit, la liste des interfaces sortantes devient NULL, PIM déclenche LDP pour supprimer le LSP point à multipoint, et LDP envoie un message de retrait d’étiquette au nœud en amont.

Fonctionnalité LSR de transit

Le LSR de transit envoie une étiquette au LSR amont vers la source de la FEC point à multipoint et installe l’état de transfert nécessaire pour transférer les paquets. Le LSR de transit peut être n’importe quel routeur compatible M-LDP.

Fonctionnalité LER d’entrée

Sur le LER d’entrée, LDP fournit les informations suivantes au PIM lors de la réception du mappage d’étiquettes :

  • (S,G)

  • Flooding next hop

Ensuite, PIM installe l’état de transfert. Si les nouvelles branches sont ajoutées ou supprimées, le saut suivant d’inondation est mis à jour en conséquence. Si toutes les branches sont supprimées en raison du retrait d’un libellé, LDP envoie des informations mises à jour au PIM. S’il existe plusieurs liaisons entre les voisins en amont et en aval, le LSP point à multipoint n’est pas équilibré en charge.

Voir également

Exemple : Configuration de la signalisation intrabande LDP multipoint pour les LSP point à multipoint

Cet exemple montre comment configurer la signalisation intrabande Multipoint LDP (M-LDP) pour le trafic multicast, en tant qu’extension du protocole PIM (Protocol Independent Multicast) ou en remplacement de PIM.

Conditions préalables

Cet exemple peut être configuré à l’aide des composants matériels et logiciels suivants :

  • Junos OS version 13.2 ou ultérieure

  • Plates-formes de routage universelles 5G MX Series MX Series ou routeurs de périphérie multiservice M Series pour les routeurs de périphérie fournisseur (PE)

  • PTX Series Routeurs de transport de paquets agissant comme des routeurs à commutation d’étiquettes de transit

  • Routeurs centraux T Series pour les routeurs centraux

REMARQUE :

Les routeurs PE peuvent également être des routeurs centraux T Series, mais ce n’est pas typique. En fonction de vos besoins d’évolutivité, les routeurs centraux peuvent également être MX Series Plates-formes de routage universelles 5G ou M Series routeurs de périphérie multiservice. Les appareils CE peuvent être d’autres routeurs ou commutateurs de Juniper Networks ou d’un autre fournisseur.

Aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise avant de configurer cet exemple.

Présentation

Configuration rapide de l’interface de ligne de commande affiche la configuration de tous les périphériques dans Figure 21. La section #d358e63__d358e831 décrit les étapes de Device EgressPE.

Figure 21 : Exemple de topologie de signalisation intrabande M-LDP pour les LSP point à multipointExemple de topologie de signalisation intrabande M-LDP pour les LSP point à multipoint

Configuration

Procédure
Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie.

Appareil src1

Entrée de l’appareil

Sortie de l’équipement PE

Appareil p6

Appareil pr3

Appareil pr4

Appareil pr5

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.

Pour configurer Device EgressPE :

  1. Configurez les interfaces.

    Activez MPLS sur les interfaces centrales. Sur les sauts suivants de sortie, vous n’avez pas besoin d’activer MPLS.

  2. Configurez IGMP sur les interfaces de sortie.

    À des fins de test, cet exemple inclut des adresses de groupe et de source statiques.

  3. Configurez MPLS sur les interfaces orientées vers le cur.

  4. Configurez BGP.

    BGP étant un protocole basé sur des stratégies, configurez et appliquez également les stratégies de routage nécessaires.

    Par exemple, vous pouvez exporter des routes statiques vers BGP.

  5. (Facultatif) Configurez une connexion d’homologue MSDP avec l’appareil pr5 afin d’interconnecter les domaines PIM disparates, permettant ainsi des RP redondants.

  6. Configurez OSPF.

  7. Configurez LDP sur les interfaces orientées cur et sur l’interface de bouclage.

  8. Activez les LSP MPLS point à multipoint.

  9. Configurez PIM sur les interfaces en aval.

  10. Configurez les paramètres RP, car cet appareil sert de point de rendez-vous (RP) PIM.

  11. Activez la signalisation intrabande M-LDP et définissez la stratégie associée.

  12. Configurez la stratégie de routage qui spécifie l’adresse racine du LSP point à multipoint et les adresses source associées.

  13. Configurez l’ID du système autonome (AS).

Résultats

À partir du mode de configuration, confirmez votre configuration en saisissant les commandes show interfaces, show protocols, show policy-optionset show routing-options. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Sortie de l’équipement PE

Configurez de même les autres périphériques de sortie.

Si vous avez terminé de configurer les périphériques, passez commit en mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification des états de jointure PIM
But

Affichez des informations sur les états de jointure PIM pour vérifier les détails M-LDP intrabande en amont et en aval. Sur le périphérique d’entrée, la commande s’affiche show pim join extensivePseudo-MLDP pour l’interface en aval. Sur la sortie, la commande s’affiche show pim join extensivePseudo-MLDP pour l’interface en amont.

Action

À partir du mode opérationnel, entrez la show pim join extensive commande.

Vérification des sources PIM
But

Vérifiez que les sources PIM contiennent les détails M-LDP intrabande attendus en amont et en aval.

Action

À partir du mode opérationnel, entrez la show pim source commande.

Vérification de la base de données LDP
But

Assurez-vous que la show ldp database commande affiche les liaisons root-to-(S,G) attendues.

Action
Recherche des informations de route pour l’étiquette MPLS
But

Affichez les informations FEC point à multipoint.

Action
Vérification des statistiques de trafic LDP
But

Surveillez les statistiques de trafic de données pour le LSP point à multipoint.

Action

Mappage du client et du serveur pour l’interopérabilité Segment Routing à LDP

La prise en charge du serveur et du client pour le mappage du routage de segments permet l’interopérabilité entre les îlots de réseau qui exécutent le routage de segments et le routage de segments (SR ou SPRING). Cette interopérabilité est utile lors d’une migration de LDP vers SR. Pendant la transition , il peut y avoir des îlots (ou domaines) avec des appareils qui prennent en charge uniquement le LDP ou uniquement le routage de segments. Pour que ces appareils puissent fonctionner, la fonctionnalité du serveur de mappage de routage de segments (SRMS) LDP et du client de mappage de routage de segments (SRMC) est requise. Vous activez ces fonctions serveur et client sur un périphérique du réseau de routage de segments.

La fonctionnalité serveur et client de mappage SR est prise en charge avec OSPF ou ISIS.

Présentation de l’interopérabilité entre le segment routing et LDP

Figure 22 montre une topologie de réseau LDP simple pour illustrer le fonctionnement de l’interopérabilité des équipements de routage de segments avec les équipements LDP. Gardez à l’esprit qu’OSPF et ISIS sont tous deux pris en charge, donc pour l’instant, nous allons garder les choses agnostiques en ce qui concerne l’IGP. L’exemple de topologie comporte six appareils, de R1 à R6, dans un réseau qui migre du protocole LDP vers le routage de segments.

Dans la topologie, les appareils R1, R2 et R3 sont configurés pour le routage de segments uniquement. Les appareils R5 et R6 font partie d’un ancien domaine LDP et ne prennent actuellement pas en charge SR. L’appareil R4 prend en charge à la fois le LDP et le routage de segments. Les adresses de bouclage de tous les périphériques sont affichées. Ces bouclages sont annoncés en tant que FEC de sortie dans le domaine LDP et en tant qu’ID de nud SR dans le domaine SR. L’interopérabilité repose sur le mappage d’un FEC LDP à un ID de nud SR, et vice versa.

Figure 22 : Exemple de topologie d’interopérabilité de segment routing vers LDPExemple de topologie d’interopérabilité de segment routing vers LDP

Pour que R1 puisse interagir avec R6, un serveur de mappage de routage de segments (SRMS) LDP et un client de mappage de routage de segments (SRMC) 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 22Sur la base de , nous dirons 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 répartir le trafic de gauche à droite. Le SRMC fournit un mappage pour le trafic qui circule de droite à gauche.

  • Flux de trafic de gauche à droite : Serveur de mappage de segment routing

    Le SRMS facilite l’interconnexion LSP entre les domaines SR et LDP. Le serveur mappe les FEC LDP aux ID de nud SR. Vous configurez les FEC LDP à mapper sous le niveau hiérarchique [edit routing-options source-packet-routing] . Normalement, vous devez mapper toutes les adresses de bouclage des nœuds LDP pour une connectivité complète. Comme indiqué ci-dessous, vous pouvez mapper des préfixes contigus dans une seule instruction de plage. Si les bouclages du nœud LDP ne sont pas contigus, vous devez définir plusieurs instructions de mappage.

    Vous appliquez la configuration de mappage SRMS sous le niveau ou [edit protocols ospf][edit protocols isis] hiérarchique. Ce choix dépend de l’IGP utilisé. Notez que les noeuds SR et LDP partagent un domaine de routage IGP commun d’une seule 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 nuds SR de mapper des préfixes LDP (FEC) aux ID de nud SR. Les routes mappées pour les préfixes LDP sont installées dans les tables de routage et des nuds SR afin de faciliter les inet.3 opérations d’entrée et mpls.0 d’assemblage LSP pour le trafic dans le sens gauche à droite.

    Le LSA étendu (ou LSP) est inondé 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 noeud SRMS n’a pas besoin d’exécuter LDP.

  • Flux de circulation de droite à gauche : Client de mappage de segment routing

    Pour interagir de droite à gauche, c’est-à-dire de l’îlot LDP vers l’îlot SR, il vous suffit d’activer la fonctionnalité client de mappage de routage de segments sur un nud parlant à la fois SR et LDP. Dans notre exemple, il s’agit de R4. Vous activez la fonctionnalité SRMC à l’aide de l’instruction au niveau de la mapping-client[edit protocols ldp] hiérarchie.

    La configuration SRMC active automatiquement une stratégie de sortie LDP pour annoncer le nœud et le préfixe SID du domaine SR en tant que FEC de sortie LDP. Les noeuds LDP sont ainsi accessibles aux noeuds du domaine SR.

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

Interopérabilité du segment routing vers LDP avec OSPF

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

  1. Définissez la fonction SRMS :

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

    REMARQUE :

    L’adresse IP utilisée comme start-prefix adresse de bouclage d’un périphérique dans le réseau LDP (R5, dans cet exemple). Pour obtenir 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éfixe.

    Notre exemple utilise des bouclages contigus, de sorte qu’un seul prefix-segment-range est affiché 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 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’appareil R2, le TLV de plage de préfixes étendu est inondé dans toute la zone OSPF. Les périphériques capables d’effectuer le 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 d’ID de segment (SID). L’index SID est également mis à jour dans la mpls.0 table de routage par les périphériques de routage de segment.

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

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

La prise en charge de l’assemblage de segments, du routage et des sauts suivants LDP avec OSPF a commencé avec 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 entre une plage de préfixes, le préfixe SID de l’ID de routeur inférieur prévaut. Dans ce cas, un message d’erreur du journal système——RPD_OSPF_PFX_SID_RANGE_CONFLICTest généré.

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

  • Le flooding du LSA opaque à préfixe étendu OSPF à travers les limites de l’AS (inter-AS) n’est pas pris en charge.

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

  • La fonctionnalité ABR de Extended Prefix Opaque LSA n’est pas prise en charge.

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

  • Le TLV de préférence du serveur de mappage de routage parexemple n’est pas pris en charge.

Interopérabilité du Segment Routing avec LDP à l’aide d’ISIS

Reportez-vous à Figure 22la section , supposons que le périphérique R2 (dans le réseau de routage de segments) est le SRMS. La configuration suivante a été ajoutée pour la fonction de mappage :

  1. Définissez la fonction SRMS :

    Cette configuration crée un bloc de mappage pour les deux adresses de bouclage de périphérique LDP dans l’exemple de topologie. L’index initial d’ID de segment (SID) mappé au bouclage de R5 est 1000. La spécification de la taille 2 entraîne le mappage de l’index SID 10001 à l’adresse de bouclage de R6.

    REMARQUE :

    L’adresse IP utilisée comme start-prefix adresse de bouclage d’un périphérique dans le réseau LDP (R5, dans cet exemple). Pour obtenir 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 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 affiché ci-dessus. Voici un exemple de mappages 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’appareil R2, le TLV de plage de préfixes étendu est inondé dans toute la zone OSPF. Les périphériques capables d’effectuer le 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 périphériques de routage de segment.

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

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

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

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

  • Le comportement d’éclatement d’avant-dernier saut pour la TLV de liaison d’étiquettes n’est pas pris en charge.

  • La publicité d’une plage de préfixes dans la 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 NSR (NonStop active Routing) et le basculement GRES (Graceful Moteur de Routage) ne sont pas pris en charge.

  • ISIS inter-niveaux n’est pas pris en charge.

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

  • La redistribution de l’itinéraire LDP en tant que prefix-sid au niveau du nœud d’assemblage n’est pas prise en charge.

Propriétés diverses de LDP

Les sections suivantes décrivent comment configurer un certain nombre de propriétés LDP diverses.

Configurer LDP pour utiliser la métrique de routage 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’instruction track-igp-metric suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

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

En configurant l’instruction, 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 no-forwarding[edit protocols mpls]traffic-engineering bgp-igp au niveau ou hiérarchie[edit logical-systems logical-system-name protocols mpls]. 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 suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

VPN LDP et Carrier-of-Carriers multi-instances

En configurant plusieurs instances de routage LDP, vous pouvez utiliser LDP pour annoncer des étiquettes dans un VPN Carrier-of-carriers à partir d’un routeur PE (Provider Provider Edge) vers un routeur CE (Carrier Customer Edge) client. Cela est particulièrement utile lorsque le client opérateur est un fournisseur d’accès à Internet (FAI) de base et qu’il souhaite restreindre les routes Internet complètes à ses routeurs PE. En utilisant LDP au lieu de BGP, l’opérateur client protège ses autres routeurs internes d’Internet. Le LDP multi-instance est également utile lorsqu’un 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 de transporteur, consultez le Guide de l’utilisateur Instances multiples pour le protocole de distribution d’étiquettes.

Configurer MPLS et LDP pour faire apparaître l’étiquette sur le routeur Ultimate-Hop

L’étiquette annoncée par défaut est l’étiquette 3 (étiquette nulle implicite). Si l’étiquette 3 est annoncée, le routeur à l’avant-dernier saut enlève l’étiquette et envoie le paquet au routeur de sortie. Si le popping ultimate-hop est activé, l’étiquette 0 (étiquette IPv4 Explicit Null) est publiée. L’popping par saut ultime garantit que tous les paquets qui traversent un réseau MPLS incluent une étiquette.

Pour configurer le popping par saut ultime, incluez l’instruction explicit-null suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

REMARQUE :

Les routeurs Juniper Networks mettent les paquets en file d’attente en fonction de l’étiquette entrante. Les routeurs d’autres fournisseurs peuvent mettre les paquets en file d’attente 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, consultez Présentation des étiquettes MPLS et Attribution des étiquettes MPLS.Présentation des étiquettes MPLS

Activer LDP sur les LSP établis par RSVP

Vous pouvez exécuter LDP sur des LSP établis par RSVP, ce qui permet de tunneliser 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 de LDP). Vous devez également configurer les LSP sur lesquels vous souhaitez que LDP opère en incluant l’instruction ldp-tunneling au niveau de la [edit protocols mpls label-switched-path lsp-name] hiérarchie :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

REMARQUE :

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

Activer 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 ce faire, vous devrez peut-être configurer manuellement la métrique RSVP lors du déploiement du tunneling LDP sur des LSP RSVP dans des réseaux hétérogènes.

Lorsqu’un routeur Juniper Networks est lié à un routeur d’un autre fournisseur via un tunnel RSVP et que le tunneling LDP est également activé, le routeur Juniper Networks peut ne pas utiliser le tunnel RSVP pour acheminer le trafic vers les destinations LDP en aval du routeur de sortie de l’autre fournisseur si la métrique du chemin RSVP est supérieure de 1 au 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 qu’il ignore la métrique LSP RSVP en incluant l’instruction ignore-lsp-metrics suivante :

Vous pouvez configurer cette instruction 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 les LSP LDP sur RSVP, vous devez également suivre la procédure décrite à la Section Activer 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 d’éviter l’introduction de segments TCP usurpés dans les flux de connexion de session LDP. Pour plus d’informations sur l’authentification TCP, consultez 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 homologue pour lequel une authentification est requise. Le mot de passe est stocké de manière cryptée.

Il est toujours possible de créer des adjacences LDP hello même lorsque les interfaces d’appairage sont configurées avec des signatures de sécurité différentes. Cependant, la session TCP ne peut pas être authentifiée et n’est jamais établie.

Vous pouvez configurer le code d’authentification des messages hachés (HMAC) et l’authentification MD5 pour les sessions LDP en tant que configuration par session ou en tant que correspondance de sous-réseau (c’est-à-dire la correspondance du préfixe le plus long). La prise en charge de l’authentification par correspondance de sous-réseau offre une certaine flexibilité dans la configuration de l’authentification pour les sessions LDP (TLDP) ciblées automatiquement. Cela facilite le déploiement des pseudowires LFA (Remote Loop Free Alternate) et FEC 129.

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

Utilisez l’instruction pour configurer l’adresse de l’extrémité session-group distante de la session LDP.

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

Vous pouvez également configurer un mécanisme de mise à jour de la clé 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 RSVP (Resource Reservation Setup Protocol).

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

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

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

Configuration de la protection de session LDP

Une session LDP est normalement créée entre une paire de routeurs connectés par une ou plusieurs liaisons. Les routeurs forment une contiguïté Hello pour chaque liaison qui les relie et associent toutes les adjacences à la session LDP correspondante. Lorsque la dernière contiguïté hello d’une session LDP disparaît, la session LDP est arrêté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 active, même s’il n’y a pas de contiguïté hello sur les liaisons reliant les deux routeurs, en configurant l’instruction session-protection . Vous pouvez éventuellement spécifier une durée en secondes à l’aide de l’option timeout . La session reste active 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 instruction, reportez-vous à la section Résumé de la déclaration.

Désactivation des interruptions SNMP pour LDP

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

Pour plus d’informations sur les interruptions SNMP LDP et la MIB LDP propriétaire, reportez-vous à l’Explorateur MIB SNMP.

Pour désactiver les interruptions SNMP pour LDP, spécifiez l’option de l’instruction trap disablelog-updown :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

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

Le protocole LDP est un protocole de distribution d’étiquettes pour les applications qui ne sont pas soumises à des techniques liées au trafic. Les labels sont distribués selon le meilleur chemin déterminé par l’IGP. Si la synchronisation entre LDP et l’IGP n’est pas maintenue, le LSP tombe en panne. Lorsque le LDP n’est pas pleinement opérationnel sur une liaison donnée (une session n’est pas établie et les étiquettes ne sont pas échangées), l’IGP annonce la liaison avec la métrique de coût maximum. Le lien n’est pas privilégié 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 du redémarrage normal.

Pour annoncer la mesure de coût maximum jusqu’à ce que LDP soit opérationnel pour la synchronisation, incluez l’instruction ldp-synchronization suivante :

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

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez configurer cette instruction, reportez-vous à la section Récapitulatif de cette instruction.

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 aux bases de données d’étiquettes LDP pour être échangées.

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

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez configurer cette instruction, reportez-vous à la section Récapitulatif de cette instruction.

Configuration de la minuterie de retrait d’étiquettes

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

Si le routeur reçoit la nouvelle étiquette avant la fin du minuteur, le minuteur de retrait de l’étiquette est annulé. Toutefois, si le délai expire, l’étiquette de la FEC est retirée de tous les routeurs en amont.

Par défaut, LDP attend 60 secondes avant de retirer les étiquettes afin d’éviter de resignaler les LSP plusieurs fois pendant que l’IGP converge. Pour configurer le délai de retrait de l’étiquette en secondes, incluez l’instruction label-withdrawal-delay suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez configurer cette instruction, reportez-vous à la section Récapitulatif de cette instruction.

Ignorer la vérification du sous-réseau LDP

Dans Junos OS version 8.4 et ultérieures, une vérification de l’adresse source LDP du sous-réseau est effectuée lors de la procédure d’établissement du voisinage. L’adresse source dans le paquet hello de la liaison LDP est comparée à l’adresse de l’interface. Cela pose un problème d’interopérabilité avec les équipements d’autres fournisseurs.

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

Cette instruction 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].

Voir également

Configuration de LDP LSP Traceroute

Vous pouvez tracer l’itinéraire suivi par un LSP signalé par LDP. Le traceroute LSP LDP est basé sur la norme RFC 4379 ( Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures. Cette fonction vous permet de tracer périodiquement tous les tracés d’une FEC. Les informations de topologie FEC sont stockées dans une base de données accessible depuis l’interface de ligne de commande.

Un changement de topologie ne déclenche pas automatiquement une trace d’un LSP LDP. Toutefois, vous pouvez lancer manuellement un traceroute. Si la demande traceroute concerne une FEC qui se trouve actuellement dans la base de données, le contenu de la base de données est mis à jour avec les résultats.

La fonctionnalité de traceroute périodique s’applique à toutes les FEC spécifiées par l’instruction oam configurée au niveau de la [edit protocols ldp] hiérarchie. Pour configurer le traceroute LSP LDP périodique, incluez l’instruction periodic-traceroute suivante :

Vous pouvez configurer cette instruction aux niveaux hiérarchiques suivants :

  • [edit protocols ldp oam]

  • [edit protocols ldp oam fec address]

Vous pouvez configurer l’instruction periodic-traceroute seule ou avec l’une des options suivantes :

  • exp: spécifiez la classe de service à utiliser lors de l’envoi de sondes.

  • fanout: spécifie le nombre maximal de sauts suivants à rechercher par noeud.

  • frequency: spécifie l’intervalle entre les tentatives de traceroute.

  • paths: spécifiez le nombre maximal de chemins à rechercher.

  • retries: spécifiez le nombre de tentatives d’envoi d’une sonde à un noeud spécifique avant d’abandonner.

  • source: spécifiez l’adresse source IPv4 à utiliser lors de l’envoi des sondes.

  • ttl: spécifiez la valeur de durée de vie maximale. Les noeuds qui se trouvent au-delà de cette valeur ne sont pas tracés.

  • wait: spécifie l’intervalle d’attente avant de renvoyer un paquet de sonde.

Collecte de statistiques sur le PLD

Les statistiques de trafic LDP indiquent le volume de trafic qui est passé par une FEC particulière sur un routeur.

Lorsque vous configurez l’instruction traffic-statistics au niveau de la hiérarchie, les statistiques de [edit protocols ldp] trafic LDP sont collectées périodiquement et écrites dans un fichier. Vous pouvez configurer la fréquence de collecte des statistiques (en secondes) à l’aide de l’option interval . L’intervalle de collecte par défaut est de 5 minutes. Vous devez configurer un fichier de statistiques LDP ; sinon, les statistiques de trafic LDP ne sont pas collectées. Si le LSP tombe en panne, les statistiques LDP sont réinitialisées.

Pour collecter des statistiques de trafic LDP, incluez l’instruction traffic-statistics suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Cette section aborde les sujets suivants :

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 laquelle les statistiques de trafic LDP sont collectées.

  • Type: type de trafic provenant d’un routeur, soit (provenant de ce routeur), soit IngressTransit (transféré via ce routeur).

  • Packets—Nombre de paquets transmis par la FEC depuis la mise en place de son LSP.

  • Bytes—Nombre d’octets de données transmises par la FEC depuis la mise à jour de son LSP.

  • Shared: une valeur indique que plusieurs préfixes sont liés à la même étiquette (par exemple, lorsque plusieurs préfixes sont annoncés avec une Yes stratégie de sortie). Dans ce cas, les statistiques de trafic LDP 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 statistiques sont résumées avant d’être affichées.

Désactivation des statistiques LDP sur le routeur à l’avant-dernier saut

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

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez configurer l’instruction traffic-statistics , reportez-vous à la section Résumé de l’instruction pour cette instruction.

REMARQUE :

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

Chaque fois que vous incluez ou supprimez cette option de la configuration, les sessions LDP sont arrêté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

Voici les problèmes liés à la collecte des statistiques LDP lors de la configuration de l’instruction traffic-statistics :

  • 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 minuteur de statistiques expire plus tard que le nouvel intervalle.

  • Une nouvelle opération de collecte de statistiques LDP ne peut pas démarrer 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 de temps 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

Les sections suivantes décrivent comment configurer les options de trace pour examiner le trafic du protocole LDP :

Suivi du trafic du protocole LDP au niveau 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 la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Utilisez l’instruction pour spécifier le nom du fichier qui reçoit la sortie de l’opération file 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 suivi suivants affichent les opérations associées à l’envoi et à la réception de divers messages LDP. Chacun peut comporter un ou plusieurs des modificateurs suivants :

  • address: traçage de l’opération des messages d’adresse et de retrait d’adresse.

  • binding: permet de tracer les opérations de liaison d’étiquettes.

  • error: conditions d’erreur de traçage.

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

  • initialization: permet de suivre le fonctionnement des messages d’initialisation.

  • label: permet de suivre l’opération des messages de demande d’étiquette, de mappage d’étiquettes, de retrait d’étiquettes et de libération d’étiquettes.

  • notification: permet de suivre le fonctionnement des messages de notification.

  • packets: traçage de l’opération d’adresse, de retrait d’adresse, d’initialisation, de demande d’étiquette, de carte d’étiquettes, de retrait d’étiquettes, de libération d’étiquettes, de notifications et de messages périodiques. Ce modificateur est équivalent à la définition des addressmodificateurs , , initializationlabel, notificationet periodic .

    Vous pouvez également configurer le modificateur d’indicateur avec la match-on address sous-option de l’indicateur.filterpackets Cela vous permet d’effectuer un suivi basé sur les adresses source et de destination des paquets.

  • path: traçage des opérations de chemin de commutation d’étiquettes.

  • path: traçage des opérations de chemin de commutation d’étiquettes.

  • periodic: permet de tracer le fonctionnement des messages hello et keepalive.

  • route: permet de 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. La FEC associée à un LSP spécifie quels paquets sont mappés à ce LSP. Les LSP sont étendus à travers un réseau lorsque chaque routeur choisit l’étiquette annoncée par le saut suivant pour la FEC et l’épisse à l’étiquette qu’il annonce à tous les autres routeurs.

Vous pouvez tracer le trafic du protocole LDP au sein d’une FEC spécifique et filtrer les instructions de trace LDP en fonction d’une FEC. Ceci est utile lorsque vous souhaitez tracer ou dépanner le trafic du protocole LDP associé à une FEC. Les indicateurs de trace suivants sont disponibles à cet effet : route, path, et binding.

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

Cette fonctionnalité présente les limitations suivantes :

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

  • Les FEC de circuit de couche 2 ne peuvent pas être filtrées.

  • Lorsque vous configurez à la fois le suivi de route et le filtrage, les routes MPLS ne sont pas affichées (elles sont bloquées par le filtre).

  • Le filtrage est déterminé par la stratégie et la valeur configurée de 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 politique que vous devez inclure est une stratégie de filtrage de route.

Exemples: Traçage du trafic du protocole LDP

Tracez les messages de chemin LDP en détail :

Tracez 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 une FEC associée au LSP :

Tableau de l'historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Version
Description
22.4R1
À partir de Junos OS Evolved version 22.4R1, vous pouvez configurer l’authentification TCP-AO ou TCP MD5 avec un sous-réseau IP afin d’inclure toute la plage d’adresses de ce sous-réseau.
22.4R1
À partir de Junos OS Evolved version 22.4R1, l’authentification TCP prend en charge VRF.
19.1
À partir de Junos OS version 19.1R1, le routeur de bordure Segment Routing-LDP peut raccorder le trafic de routage de segments au saut suivant LDP et vice versa.
16.1
À partir de Junos OS version 16.1, M-LDP peut signaler des LSP point à multipoint au niveau ASBR ou en transit ou en sortie lorsque l’adresse racine est une route BGP qui est ensuite résolue de manière récursive sur un LSP MPLS.
14.1
À partir de Junos OS version 14.1, afin de migrer les services IPTV existants du multicast IP natif vers le multicast MPLS, vous devez effectuer une transition en douceur de PIM vers les LSP point à multipoint M-LDP avec un minimum de panne.