Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

configuration de routes alternatives sans boucle pour OSPF

Alternatives sans boucle par préfixe pour OSPF

Dans certaines topologies et certains scénarios d’utilisation, lorsque plusieurs destinations proviennent du même préfixe et qu’il n’y a pas de LFA viable pour le meilleur émetteur de préfixe, alors qu’un expéditeur qui n’est pas le meilleur préfixe en a un. Le LFA par préfixe est une technologie par laquelle le LFA vers un émetteur de préfixe non meilleur peut être utilisé à la place du LFA vers le meilleur émetteur de préfixe pour fournir une réparation locale. Cela peut également être utilisé pour augmenter la couverture de réparation locale pour le protocole OSPF.

Alternatives libres de boucles par préfixe (LFA) : les alternatives libres de boucles (LFA) sont une technologie par laquelle un voisin peut être utilisé comme saut suivant de secours pour fournir un chemin de réparation local pour que le trafic circule temporairement en cas de défaillance dans le saut suivant principal (nœud ou lien). Pour cela, l’exigence de base est que le voisin de secours sélectionné fournisse un chemin libre de boucle par rapport au saut suivant principal vers une destination, à l’origine d’un ensemble de préfixes IGP (Interior Gateway Protocol).

La topologie suivante explique le cas de déploiement dans lequel la fonctionnalité LFA par préfixe est applicable.

Figure 1 : Scénario d’utilisation de la zone LFA par préfixe Per-Prefix LFA Usage Scenario

ABR1 et ABR2 sont des routeurs de limite de zone (ABRs), connectés à un réseau central IPv6, qui annoncent le LSA de synthèse pour le préfixe 10.0.1.0/24 avec une métrique de 10. De plus, du point de vue du routeur PE, ABR1 est le meilleur émetteur de préfixe pour 10.0.1.0/24. Dans ce cas, P2 n’est pas une LFA valide pour ABR1 en raison des chemins multiples à coût égal (ECMP) {P2, PE, P1, ABR1} et {P2, ABR2, ABR1} qui provoquent une reconduction d’une partie du trafic via le PE du routeur (pas de LFA valide). Cependant, pour ABR2, qui est également un préfixe à l’origine de 10.0.1.0/24, P2 est un LFA valide car le seul chemin est {P2, ABR2}.

Configuration de LFA par préfixe pour OSPF

Par préfixe, LFA est un mécanisme par lequel LFA à un émetteur de préfixe non meilleur peut être utilisé à la place de LFA à l’expéditeur du meilleur préfixe pour fournir une réparation locale. Dans ce cas, LFA par préfixe peut être utilisé pour augmenter la couverture de réparation locale pour le protocole OSPF.

Loop Free Alternates (LFA) est un mécanisme par lequel un voisin peut être utilisé comme saut suivant de secours pour fournir un chemin de réparation local pour que le trafic circule temporairement en cas de défaillance dans le saut suivant principal (nœud ou lien). Pour cela, l’exigence de base est que le voisin de secours sélectionné fournisse un chemin libre de boucle par rapport au saut suivant principal vers une destination à l’origine d’un ensemble de préfixes IGP. Dans certaines topologies et certains scénarios d’utilisation, il est possible que plusieurs destinations soient à l’origine du même préfixe et qu’il n’y ait pas de LFA viable pour le meilleur émetteur de préfixe, alors qu’un autre émetteur de préfixe en a un. Par préfixe, LFA est un mécanisme par lequel LFA à un émetteur de préfixe non meilleur peut être utilisé à la place de LFA à l’expéditeur du meilleur préfixe pour fournir une réparation locale. Dans ce cas, LFA par préfixe peut être utilisé pour augmenter la couverture de réparation locale pour le protocole OSPF.

Pour configurer par préfixe LFA pour une interface OSPF :

Configurez l’instruction de per-prefix-calculation configuration au niveau de la [edit protocols (ospf | ospf3) backup-spf-options] hiérarchie.

Présentation des routes alternatives sans boucle pour OSPF

La prise en charge des routes alternatives sans boucle OSPF ajoute essentiellement une fonctionnalité de reroutage rapide IP pour OSPF. Junos OS précalcule les routes de sauvegarde sans boucle pour toutes les routes OSPF. Ces routes de sauvegarde sont préinstallées dans le moteur de transfert de paquets, qui effectue une réparation locale et implémente le chemin de sauvegarde lorsque la liaison pour un tronçon suivant principal d’une route particulière n’est plus disponible. Grâce à la réparation locale, le moteur de transfert de paquets peut corriger une défaillance de chemin avant qu’il ne reçoive les chemins précalculés du moteur de routage. La réparation locale réduit le temps nécessaire pour réacheminer le trafic à moins de 50 millisecondes. En revanche, la réparation globale peut prendre jusqu’à 800 millisecondes pour calculer un nouvel itinéraire. La réparation locale permet au trafic de continuer à être acheminé à l’aide d’un chemin de secours jusqu’à ce que la réparation globale soit en mesure de calculer un nouvel itinéraire.

Un chemin sans boucle est un chemin qui ne transfère pas le trafic à travers le périphérique de routage pour atteindre une destination donnée. C’est-à-dire qu’un voisin dont le chemin le plus court vers la destination traverse le périphérique de routage qui n’est pas utilisé comme route de secours vers cette destination. Pour déterminer des chemins alternatifs sans boucle pour les routes OSPF, Junos OS exécute des calculs shortest-path-first (SPF) sur chaque voisin à un saut. Vous pouvez activer la prise en charge d’autres routes sans boucle sur n’importe quelle interface OSPF. Étant donné qu’il est courant d’activer LDP sur une interface pour laquelle OSPF est déjà activé, cette fonctionnalité prend également en charge les chemins de commutation d’étiquettes (LSP) LDP.

Note:

Si vous activez la prise en charge d’autres routes sans boucle sur une interface configurée à la fois pour LDP et OSPF, vous pouvez utiliser la commande pour tracer le traceroute chemin actif vers le saut suivant principal.

Le niveau de couverture de secours disponible via les routes OSPF dépend de la topologie réelle du réseau et est généralement inférieur à 100 % pour toutes les destinations sur un périphérique de routage donné. Vous pouvez étendre la couverture de sauvegarde pour inclure les chemins RSVP LSP.

Junos OS fournit trois mécanismes de redondance des routes pour OSPF via d’autres routes sans boucles :

  • Protection des liaisons : offre une protection par liaison du trafic. Utilisez la protection des liens lorsque vous supposez qu’un seul lien peut devenir indisponible, mais que le nœud voisin sur le chemin principal serait toujours disponible via une autre interface.

  • Protection de la liaison de nœud : établit un chemin alternatif via un périphérique de routage complètement différent. Utilisez la protection de liaison de nœud lorsque vous supposez que l’accès à un nœud est perdu lorsqu’un lien n’est plus disponible. Par conséquent, Junos OS calcule un chemin de secours qui évite le périphérique de routage de saut suivant principal.

  • Alternatives sans boucle (LFA) par préfixe : il s’agit d’une technologie permettant d’utiliser un voisin comme tronçon suivant de secours pour fournir un chemin de réparation local permettant au trafic de circuler temporairement en cas de défaillance dans le tronçon suivant principal (nœud ou lien). Pour cela, l’exigence de base est que le voisin de secours sélectionné fournisse un chemin sans boucle par rapport à un saut suivant principal vers une destination, à l’origine d’un ensemble de préfixes IGP (Interior Gateway Protocol).

    Dans certaines topologies et certains scénarios d’utilisation, il est possible que plusieurs destinations proviennent du même préfixe et qu’il n’y ait pas de LFA viable pour le meilleur émetteur de préfixe, alors qu’un autre émetteur de préfixe a une LFA viable. Par préfixe LFA est un mécanisme par lequel LFA à un émetteur de préfixe non meilleur peut être utilisé à la place de LFA à l’émetteur du meilleur préfixe pour fournir une réparation locale. Dans ce cas, LFA par préfixe peut être utilisé pour augmenter la couverture de réparation locale pour le protocole OSPF.

Lorsque vous activez la protection de liaison ou la protection de liaison de nœud sur une interface OSPF, Junos OS crée un chemin alternatif vers le saut suivant principal pour toutes les routes de destination qui traversent une interface protégée.

Exemple : configuration d’itinéraires alternatifs sans boucle pour OSPF

Cet exemple illustre l’utilisation de la protection de liaison pour les interfaces sur lesquelles OSPF est activé.

Lorsque vous activez la protection des liaisons, Junos OS crée un chemin alternatif vers le saut suivant principal pour toutes les routes de destination qui traversent une interface protégée. Utilisez la protection des liens lorsque vous supposez qu’un seul lien peut devenir indisponible, mais que le nœud voisin sera toujours disponible via une autre interface.

Exigences

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

Aperçu

Dans cet exemple, six voisins OSPF sont configurés avec une protection de liaison. Junos OS crée alors un chemin alternatif vers le tronçon suivant principal pour toutes les routes de destination qui traversent chaque interface protégée. La protection des liens est utilisée ici, car même si un lien devient indisponible, le nœud voisin sera toujours disponible via une autre interface.

L’exemple montre deux topologies. L’une est la topologie par défaut et l’autre est la topologie vocale. Pour plus d’informations sur le routage multitopologique, reportez-vous au Guide de l’utilisateur du routage multitopologique.

L’exemple inclut également des LSP RSVP configurés en tant que LSP de secours pour les interfaces OSPF protégées.

Topologie

La figure 2 illustre l’exemple de réseau.

Figure 2 : protection des OSPF Link Protection liaisons OSPF

CLI Quick Configuration affiche la configuration de tous les périphériques de la Figure 2.

La section #d148e68__d148e786 décrit les étapes sur l’appareil R1.

Configuration

Configuration rapide de la CLI

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 R1

Appareil R2

Appareil R3

Appareil R4

Appareil R5

Appareil R6

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 de configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.

Pour configurer l’appareil R1 :

  1. Configurez les interfaces des appareils.

  2. Étendez la couverture de sauvegarde pour inclure les chemins RSVP LSP.

  3. Activez MPLS sur les interfaces et configurez les LSP de secours sur l’appareil R3.

  4. Configurez les connexions OSPF, les métriques des liens et la protection des liens.

  5. (Facultatif) Configurez une topologie OSPF spécifique pour le trafic vocal.

  6. Activez LDP sur les interfaces.

  7. (Facultatif) Configurez l’équilibrage de charge par paquet.

  8. Configurez le processus de protocole de routage (rpd) pour demander un accusé de réception lors de la création d’un nouveau saut suivant de transfert.

    Nous vous recommandons de configurer l’instruction lorsque des indirect-next-hop-change-acknowledgements mécanismes de protection sont utilisés. Cela inclut la protection MPLS RSVP telle que le reroutage rapide (FRR) ainsi que la protection IGP (Interior Gateway Protocol), la liaison alternative sans boucle (LFA) ou la protection des nœuds.

Résultats

À partir du mode configuration, confirmez votre configuration en entrant les show interfacescommandes , 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.

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 routes sur l’appareil R1

But

Sur le périphérique R1, vérifiez les routes OSPF dans la table de routage.

Action
Signification

Comme prévu, l’appareil R1 dispose de plusieurs itinéraires potentiels vers chaque destination.

Vérification de la couverture de secours

But

Sur l’appareil R1, utilisez la show (ospf | ospf3) backup coverage commande pour vérifier le niveau de couverture de sauvegarde disponible pour tous les nœuds et préfixes du réseau.

Action

Vérification des LSP de sauvegarde

But

Sur le périphérique R1, utilisez la show (ospf | ospf3) backup lsp commande pour vérifier les LSP désignés comme routes de secours pour les routes OSPF.

Action

Vérification des voisins de sauvegarde

But

Sur l’appareil R1, utilisez la show (ospf | ospf3) backup neighbor commande pour vérifier les voisins à travers lesquels les sauts suivants directs pour les chemins de sauvegarde sont disponibles.

Action

Vérification des calculs SPF

But

Sur l’appareil R1, utilisez la commande pour vérifier les show (ospf | ospf3) backup spf detail calculs OSPF shortest-path-first (SPF) pour les chemins de secours. Pour limiter la sortie, la topologie vocale est spécifiée dans la commande.

Action

Exclusion d’une interface OSPF en tant que sauvegarde d’une interface protégée

Par défaut, toutes les interfaces OSPF qui appartiennent à l’instance par défaut ou à une instance de routage spécifique sont éligibles en tant qu’interface de secours pour les interfaces configurées avec la protection de liaison ou la protection de liaison de nœud. Vous pouvez spécifier que toute interface OSPF doit être exclue du fonctionnement en tant qu’interface de secours pour les interfaces protégées.

Pour exclure une interface OSPF en tant qu’interface de secours d’une interface protégée :

  • Incluez l’instruction no-eligible-backup au niveau de la [edit protocols (ospf | ospf3) area area-id interface interface-name] hiérarchie.

Dans l’exemple suivant, l’interface so-0/0/0.0 a été configurée pour interdire le trafic de secours pour le trafic destiné à une interface protégée. Cela signifie qu’en cas de défaillance d’un chemin de saut suivant ou d’un nœud voisin d’une interface protégée, l’interface so-0/0/0.0 ne peut pas être utilisée pour transmettre le trafic vers un chemin de secours.

Configuration des options SPF de sauvegarde pour les interfaces OSPF protégées

Par défaut, si au moins une interface OSPF est configurée pour la protection des liens ou des liaisons de nœud, Junos OS calcule les sauts suivants de sauvegarde pour toutes les topologies d’une instance OSPF. Vous pouvez configurer les options SPF (Shortest-Path-First) de sauvegarde suivantes pour remplacer le comportement par défaut :

  • Désactivez le calcul des sauts suivants de sauvegarde pour une instance OSPF ou une topologie spécifique dans une instance.

  • Empêchez l’installation de sauts suivants de sauvegarde dans la table de routage ou la table de transfert d’une instance OSPF ou d’une topologie spécifique dans une instance.

  • Limitez le calcul des sauts suivants de sauvegarde à un sous-ensemble de chemins tels que définis dans la RFC 5286, Spécification de base pour le reroutage rapide IP : alternatives sans boucle.

Vous pouvez désactiver l’algorithme SPF de sauvegarde pour une instance OSPF ou une topologie spécifique dans une instance. Cela empêche le calcul des sauts suivants de sauvegarde pour cette instance ou topologie OSPF.

Pour désactiver le calcul des sauts suivants de sauvegarde pour une instance ou une topologie OSPF :

  • Incluez l’instruction disable au niveau de la [edit protocols (ospf | ospf3) backup-spf-options] hiérarchie ou [edit protocols ospf backup-spf-options topology topology-name]

Dans l’exemple suivant, le calcul des sauts suivants de sauvegarde est désactivé pour la voix de topologie OSPF :

Vous pouvez configurer le périphérique de routage pour empêcher l’installation de sauts suivants de sauvegarde dans la table de routage ou la table de transfert d’une instance OSPF, ou d’une topologie spécifique dans une instance OSPF. L’algorithme SPF continue de calculer les sauts suivants de sauvegarde, mais ils ne sont pas installés.

Pour empêcher le périphérique de routage d’installer des sauts suivants de sauvegarde dans la table de routage ou la table de transfert :

  • Incluez l’instruction no-install au niveau de [edit protocols ospf topology topology-name] la [edit protocols (ospf | ospf3) backup-spf-options] hiérarchie.

Dans l’exemple suivant, les sauts suivants de sauvegarde pour la voix de la topologie OSPF ne sont pas installés dans la table de routage ou la table de transfert. Tous les sauts suivants de sauvegarde calculés pour d’autres instances ou topologies OSPF continuent d’être installés.

Vous pouvez limiter le calcul des sauts suivants de sauvegarde aux chemins en aval, comme défini dans la RFC 5286. Vous pouvez spécifier à Junos OS d’utiliser uniquement les chemins en aval comme sauts de secours pour les interfaces protégées d’une instance OSPF ou d’une topologie spécifique dans une instance OSPF. Dans un chemin en aval, la distance entre le voisin de secours et la destination doit être inférieure à la distance entre le périphérique de routage calculateur et la destination. L’utilisation de chemins en aval uniquement comme chemins alternatifs sans boucle pour les interfaces protégées garantit que ces chemins n’entraînent pas de microboucles. Cependant, la couverture de sauvegarde de votre réseau risque de ne pas être optimale.

Pour limiter le calcul des sauts suivants de sauvegarde aux chemins descendants :

  • Incluez l’instruction downstream-paths-only au niveau de la [edit protocols (ospf | ospf3) backup-spf-options] hiérarchie ou [edit protocols ospf backup-spf-options topology topology-name]

Dans l’exemple suivant, seuls les chemins en aval sont calculés en tant que sauts suivants de secours pour la voix de topologie :

Configuration des chemins de commutation d’étiquettes RSVP en tant que chemins de secours pour OSPF

Lors de la configuration d’une interface OSPF pour la protection des liens ou des liaisons de nœud, le calcul SPF (Shortest-path-first) des chemins de secours pour les voisins à un saut peut entraîner une couverture de secours inférieure à 100 % pour une topologie de réseau spécifique. Vous pouvez améliorer la couverture des chemins de commutation d’étiquettes (LSP) OSPF et LDP en configurant les LSP RSVP en tant que chemins d’accès de secours.

Lors de la configuration d’un LSP, vous devez spécifier l’adresse IP du routeur de sortie.

Note:

Les LSP RSVP peuvent être utilisés comme chemins d’accès de secours uniquement pour la topologie par défaut pour OSPFv2 et non pour une topologie configurée. En outre, RSVP LSP ne peut pas être utilisé comme chemin de secours pour les instances autres que celles par défaut pour OSPFv2 ou OSPFv3.

Pour configurer un LSP RSVP spécifique en tant que chemin d’accès secondaire :

  1. Incluez l’instruction backup au niveau de la [edit protocols mpls labeled-switched-path lsp-name] hiérarchie.
  2. Spécifiez l’adresse du routeur de sortie en incluant l’instruction to ip-address au niveau de la [edit protocols mpls label-switched-path] hiérarchie.

Dans l’exemple suivant, le LSP RSVP f-to-g est configuré en tant que LSP de secours pour les interfaces OSPF protégées. Le routeur de sortie est configuré avec l’adresse IP 192.168.1.4.

Présentation de la fonction LFA distante sur tunnels LDP dans les réseaux OSPF

Dans un réseau OSPF, une alternative libre de boucle (LFA) est un voisin directement connecté qui fournit des chemins de secours précalculés vers les destinations accessibles via le lien protégé sur le point de réparation local (PLR). Un LFA distant n’est pas directement connecté au PLR et fournit des chemins de secours précalculés à l’aide de tunnels LDP créés dynamiquement vers le nœud LFA distant. Le DPP utilise ce chemin de secours LFA distant lorsque la liaison principale tombe en panne. L’objectif principal de la LFA distante est d’augmenter la couverture de secours pour les réseaux OSPF et de fournir une protection pour les anneaux métropolitains de couche 1.

Les LFA ne fournissent pas une couverture de secours complète pour les réseaux OSPF. Il s’agit d’un revers majeur pour les réseaux Ethernet métropolitains qui ont souvent la forme de topologies en anneau. Pour surmonter ce problème, il est couramment utilisé des tunnels de sauvegarde RSVP-TE (Resource Reservation Protocol - Traffic Engineering) pour étendre la couverture de sauvegarde. Cependant, la majorité des fournisseurs de réseaux ont déjà implémenté LDP comme protocole d’établissement de tunnel MPLS et ne souhaitent pas implémenter le protocole RSVP-TE uniquement pour la couverture de secours. Le protocole LDP active automatiquement les tunnels de transport vers toutes les destinations potentielles d’un réseau OSPF et constitue donc le protocole privilégié. Le LDP existant implémenté pour la configuration du tunnel MPLS peut être réutilisé pour protéger les réseaux OSPF et les destinations LDP suivantes, éliminant ainsi le besoin de tunnels de sauvegarde RSVP-TE pour la couverture de secours.

Pour calculer le chemin de sauvegarde LFA distant, le protocole OSPF détermine le noeud LFA distant de la manière suivante :

  1. Calcule d’abord le chemin le plus court inverse à partir du routeur adjacent à travers la liaison protégée d’un DPP. Le chemin le plus court inverse utilise d’abord la mesure du lien entrant au lieu de la mesure du lien sortant pour atteindre un nœud voisin.

    Le résultat est un ensemble de liens et de nœuds, qui est le chemin le plus court entre chaque nœud Leaf et le nœud racine.

  2. Calcule d’abord le chemin le plus court (SPF) sur les routeurs adjacents restants pour trouver la liste des nœuds qui peuvent être atteints sans traverser la liaison protégée.

    Le résultat est un autre ensemble de liens et de nœuds sur le chemin le plus court entre le nœud racine et tous les nœuds leaf.

  3. Détermine les noeuds communs à partir des résultats ci-dessus. Ces noeuds sont les zones défavorisées distantes.

OSPF écoute les étiquettes annoncées pour les routes LDP. Pour chaque route LDP annoncée, OSPF vérifie si elle contient un saut suivant fourni par LDP. Si la route OSPF correspondante dispose d’un prochain saut de sauvegarde, l’OSPF exécute la stratégie de sauvegarde et ajoute une route de suivi supplémentaire avec le chemin de commutation d’étiquettes LDP correspondant comme saut suivant de sauvegarde. S’il n’y a pas de sauts suivants de secours, LDP construit un tunnel LDP dynamique vers le LFA distant, et LDP établit une adjacence ciblée entre le nœud LFA distant et le nœud PLR. Cette route de sauvegarde a deux étiquettes LDP. L’étiquette supérieure est la route OSPF, qui indique le chemin de secours entre le PLR et la route LFA distante. L’étiquette inférieure est le chemin de commutation d’étiquettes MPLS LDP qui indique l’itinéraire permettant d’atteindre la destination finale à partir de la LFA distante. Lorsqu’une session LDP tombe en panne et qu’un tunnel distant n’est plus disponible, OSPF modifie toutes les routes qui ont utilisé ce tunnel LDP de secours.

Note:

Actuellement, Junos OS ne prend en charge que les LSP de transport IPv4. Si vous devez réutiliser les LSP de transport IPv4 pour les réseaux IGP IPv6, ajoutez une étiquette NULL explicite IPv6 à la pile d’étiquettes de l’itinéraire de suivi. Le système convertit automatiquement le LSP IPv4 en LSP IPv6.

Le LDP peut être vulnérable en raison d’une contiguïté ciblée automatiquement, et ces menaces peuvent être atténuées à l’aide de tout ou partie des mécanismes suivants :

  • Les zones de développement distantes distantes qui se trouvent à plusieurs sauts utilisent des messages de bonjour prolongés pour indiquer leur volonté d’établir une session LDP ciblée. Une LFA distante peut réduire le risque d’usurpation de messages de bonjour étendus en les filtrant et en n’acceptant que ceux provenant de sources autorisées par une liste d’accès ou de filtrage.

  • Il est nécessaire d’authentifier auprès de TCP-MD5 toutes les sessions LDP auto-ciblées dans le domaine IGP/LDP donné à l’aide de groupes d’application ou de l’authentification LDP au niveau global.

  • Par mesure de sécurité supplémentaire, les routeurs de point de terminaison de tunnel de réparation ou de tunnel distant doivent être attribués à partir d’un ensemble d’adresses inaccessibles depuis l’extérieur du domaine de routage.

Configuration de la sauvegarde LFA distante sur tunnels LDP dans un réseau OSPF

L’objectif principal d’une alternative sans boucle distante (LFA) est d’augmenter la couverture de secours pour les routes OSPF et de fournir une protection, en particulier pour les anneaux métropolitains de couche 1. Le LDP existant implémenté pour la configuration de tunnel MPLS peut être réutilisé pour protéger les réseaux OSPF et les destinations LDP ultérieures. Le protocole OSPF crée un tunnel LDP dynamique pour atteindre le nœud LFA distant à partir du point de réparation locale (PLR). Le DPP utilise ce chemin de secours LFA distant lorsque la liaison principale tombe en panne.

Avant de configurer des tunnels LFA sur LDP distants dans un réseau OSPF, vous devez effectuer les opérations suivantes :

  1. Activez LDP sur l’interface de bouclage.

    Configurez une interface de bouclage, car il est impossible de former une adjacence ciblée LDP sans interface de bouclage. La contiguïté ciblée LDP est essentielle pour déterminer les chemins de sauvegarde LFA distants.

  2. Assurez-vous que le LFA distant autorise la découverte asymétrique du voisin distant, c’est-à-dire qu’il doit envoyer des messages hello ciblés périodiques au routeur qui a initié le voisin distant pour l’adjacence ciblée automatique LDP.

  3. Configurez la protection de liaison ou la protection de liaison de nœud sur le PLR.

Pour configurer la sauvegarde LFA distante sur tunnels LDP dans un réseau OSPF :

  1. Activez la sauvegarde LFA distante pour déterminer le saut suivant de la sauvegarde à l’aide d’un chemin de commutation d’étiquettes LDP dynamique.
  2. Activez des sessions LDP ciblées automatiquement à l’aide des adresses de bouclage entre le PLR et le nœud LFA distant.
  3. Spécifiez un intervalle de temps pendant lequel les sessions LDP ciblées sont maintenues même après la défaillance du nœud LFA distant.

    Par exemple, pour définir une valeur de délai de démontage de 60 secondes :

  4. Spécifiez le nombre maximal de sessions LDP ciblées automatiquement pour optimiser l’utilisation de la mémoire.

    Par exemple, pour définir un nombre maximum de sessions autorisées à 20 :

Exemple : Configuration de tunnels LFA distants sur LDP dans des réseaux OSPF

Dans un réseau OSPF, une alternative sans boucle (LFA) est un voisin directement connecté qui fournit des chemins de secours précalculés vers les destinations accessibles via le lien protégé sur le point de réparation local (PLR). Un LFA distant n’est pas directement connecté au PLR et fournit des chemins de secours précalculés à l’aide de tunnels LDP créés dynamiquement vers le nœud LFA distant. Le DPP utilise ce chemin de secours LFA distant lorsque la liaison principale tombe en panne. L’objectif principal de la LFA distante est d’augmenter la couverture de secours pour les réseaux OSPF et de fournir une protection pour les anneaux métropolitains de couche 1. Cet exemple montre comment configurer LFA distant pour les tunnels LDP dans un réseau OSPF afin d’étendre la protection des sauvegardes.

Exigences

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

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

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

Avant de configurer des tunnels LFA sur LDP distants dans un réseau OSPF, vérifiez les points suivants :

  • LDP est activé sur l’interface de bouclage. Sans interface de bouclage, il est impossible de former une contiguïté ciblée LDP. Il n’est pas possible de configurer la fonction LFA distante sans une contiguïté ciblée LDP.

  • Le LFA distant doit permettre la découverte asymétrique du voisin distant, c’est-à-dire qu’il doit envoyer des bonjours ciblés périodiques au routeur qui a initié le voisin distant pour l’adjacence ciblée automatique LDP.

  • La protection de liaison ou de liaison de nœud doit être configurée sur le point de réparation local (PLR).

Aperçu

L’exemple inclut neuf routeurs dans une topologie en anneau. Configurez le protocole OSPF sur les interfaces directement connectées. L’appareil R6 est le DPP. Cet exemple vérifie que Junos OS met à jour la table de routage du périphérique R6 avec les routes de saut suivant LDP comme route de secours.

Topologie

Dans la topologie, la Figure 3 montre que la configuration des tunnels LFA sur LDP distants dans les réseaux OSPF est configurée sur l’équipement R6.

Figure 3 : exemple de tunnel Example Remote LFA over LDP Tunnels LFA distant sur LDP

Configuration

Configuration rapide de la CLI

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

Réf. 3

R4

Réf. 5

Réf. 6

Réf. R7

Réf. R8

Configuration de l’appareil R6

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 R6 :

  1. Configurez les interfaces.

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

  3. Configurez l’ID du routeur. Appliquez la stratégie à la table de transfert du routeur local à l’aide de l’instruction export.

  4. Activez la sauvegarde LFA distante, qui calcule le saut suivant de la sauvegarde à l’aide du chemin de commutation d’étiquettes LDP dynamique.

  5. Configurez l’ingénierie de trafic et la protection des liens pour les interfaces dans la zone OSPF.

  6. Spécifiez un intervalle de temps pendant lequel les sessions LDP ciblées sont maintenues lorsque la LFA distante tombe en panne, et spécifiez un nombre maximal de sessions LDP ciblées automatiquement pour optimiser l’utilisation de la mémoire.

  7. Configurez les protocoles LDP sur les interfaces.

  8. Configurez les options de stratégie pour équilibrer la charge de chaque paquet de la stratégie de routage de déclaration de stratégie.

Résultats

À partir du mode configuration, confirmez votre configuration en entrant les show interfacescommandes , 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.

Si vous avez terminé de configurer l’appareil, entrez 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 l’appareil R6, à partir du mode opérationnel, exécutez la show route 10.6.6.6/24 commande pour afficher les routes dans la table de routage.

Signification

La sortie affiche toutes les routes de la table de routage de l’appareil R6.

Vérification des routes LDP

But

Vérifiez les routes LDP ciblées automatiquement.

Action

À partir du mode opérationnel, entrez la show ldp session auto-targeted detail commande.

Vérification des routes OSPF

But

Affichez toutes les routes de sauvegarde LDP dans la table de routage OSPF de l’équipement R6.

Action

Sur l’appareil R6, à partir du mode opérationnel, exécutez la show ospf route commande pour afficher les routes dans la table de routage OSPF.

Signification

La sortie affiche toutes les routes de sauvegarde LDP dans la table de routage OSPF du périphérique R6.

Vérification du noeud du chemin d’accès de secours désigné

But

Affichez le saut suivant de la LFA à distance déterminé pour une destination donnée.

Action

À partir du mode opérationnel, entrez la show ospf backup spf results commande.

Signification

La sortie indique si une interface ou un nœud spécifique a été désigné comme chemin de secours distant et pourquoi.

Vérification des voisins de sauvegarde

But

Afficher les voisins de secours pour l’appareil R6

Action

À partir du mode opérationnel, entrez la show ospf backup neighbor commande.

Signification

La sortie affiche les voisins de secours disponibles pour la zone 0.0.0.0.