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 libres par boucle de préfixe pour OSPF

Dans certaines topologies et scénarios d’utilisation, lorsque plusieurs destinations sont à l’origine du même préfixe et qu’il n’existe pas de LFA viable vers le meilleur expéditeur de préfixe, alors qu’un expéditeur de préfixe non best en possède un. Par préfixe LFA est une technologie par laquelle il est possible d’utiliser le LFA à un expéditeur de préfixe non best en lieu et place du LFA par le meilleur expéditeur de préfixe afin de fournir une réparation locale. Cela peut également être utilisé pour augmenter la couverture des réparations locales pour le protocole OSPF.

LFA (Loop Free Alternates) par préfixe : la technologie LFA (Loop Free Alternates) permet aux voisins de fournir un chemin de réparation local permettant au trafic de circuler temporairement en cas de défaillance du saut suivant principal (nœud ou liaison). Pour cela, l’exigence de base est que le voisin de secours sélectionné fournit un chemin sans boucle en ce qui concerne le saut principal suivant 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 fonction LFA de préfixe est applicable.

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

L’ABR1 et l’ABR2 sont des routeurs limite de zone (ABR), deux dotés d’un réseau central IPv6, qui présente la LSA résumée pour le préfixe 10.0.1.0/24 avec une métrique de 10. De plus, du point de vue du routeur PE, l’ABR1 est le meilleur expéditeur 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 multi-chemins à coût égal (ECMP) {P2, PE, P1, ABR1} et {P2, ABR2, ABR1} qui entraînent une certaine boucle du trafic via le pe du routeur (pas de LFA valide). Toutefois, pour ABR2, qui est également l’expéditeur de préfixe pour 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, le LFA est un mécanisme permettant d’utiliser LFA à un expéditeur de préfixe non best en lieu et place du LFA par le meilleur expéditeur de préfixe afin de fournir une réparation locale. Dans ce cas, par préfixe, LFA peut être utilisé pour augmenter la couverture de réparation locale du protocole OSPF.

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

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

Configurez l’instruction per-prefix-calculation de 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 permet d’ajouter une fonctionnalité de reroutage rapide IP pour OSPF. Junos OS précompute des routes de sauvegarde sans boucle pour tous les routes OSPF. Ces routes de secours sont préinstallées dans le moteur de transfert de paquets, qui effectue une réparation locale et implémente le chemin de secours lorsque la liaison pour un saut principal suivant pour un routage particulier n’est plus disponible. Grâce à la réparation locale, le moteur de transfert de paquets peut corriger une défaillance de chemin avant de recevoir des chemins précomputés du moteur de routage. La réparation locale réduit le temps nécessaire pour rediriger le trafic à moins de 50 millisecondes. En revanche, la réparation globale peut prendre jusqu’à 800 millisecondes pour calculer une nouvelle route. Les réparations locales permettent de continuer à acheminer le trafic à l’aide d’un chemin de secours jusqu’à ce que la réparation globale soit capable de calculer une nouvelle route.

Un chemin sans boucle n’est pas capable de transférer le trafic vers une destination donnée via l’équipement de routage. C’est-à-dire un voisin dont le chemin le plus court d’abord vers la destination traverse l’équipement 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 SPF (Path-First) les plus courts sur chaque voisin d’un saut. Vous pouvez activer la prise en charge de routes alternatives sans boucle sur n’importe quelle interface OSPF. Étant donné qu’il est courant d’activer le 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 de routes alternatives sans boucle sur une interface configurée à la fois pour LDP et OSPF, vous pouvez utiliser la traceroute commande pour tracer le 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 n’importe quel équipement de routage. Vous pouvez étendre la couverture de sauvegarde aux chemins LSP RSVP.

Junos OS fournit trois mécanismes de redondance de route pour OSPF par le biais de routes alternatives sans boucle :

  • Protection des liaisons : offre une protection du trafic par lien. Utilisez la protection des liaisons lorsque vous partez du principe qu’une seule liaison peut ne plus être disponible, mais que le nœud voisin du chemin principal reste disponible via une autre interface.

  • Protection des liaisons de nœuds : établit un chemin alternatif via un autre équipement de routage. Utilisez la protection des liaisons de nœud lorsque vous partez du principe que l’accès à un nœud est perdu lorsqu’une liaison n’est plus disponible. En conséquence, Junos OS calcule un chemin de secours qui évite le périphérique de routage principal du saut suivant.

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

    Dans certaines topologies et scénarios d’utilisation, il peut être possible que plusieurs destinations soient à l’origine du même préfixe et qu’il n’existe pas de LFA viable vers le meilleur expéditeur de préfixe, tandis qu’un expéditeur de préfixe non best possède un LFA viable. Le LFA par préfixe est un mécanisme permettant d’utiliser le LFA à un expéditeur de préfixe non best en lieu et place du LFA par le meilleur expéditeur de préfixe afin de fournir une réparation locale. Dans ce cas, par préfixe, LFA peut être utilisé pour augmenter la couverture de réparation locale du protocole OSPF.

Lorsque vous activez la protection des liaisons ou des liaisons 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.

Exclusion d’une interface OSPF en tant que sauvegarde pour 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 des liaisons ou des liaisons de nœud. Vous pouvez spécifier que toute interface OSPF ne peut pas fonctionner comme une interface de secours pour les interfaces protégées.

Pour exclure une interface OSPF en tant qu’interface de sauvegarde pour une interface protégée :

  • Inclure l’énoncé 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 que si un chemin ou un nœud voisin d’un saut suivant pour une interface protégée échoue, l’interface so-0/0/0.0 ne peut pas être utilisée pour transmettre le trafic à 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 liaisons ou des liaisons de nœud, Junos OS calcule les sauts de secours pour toutes les topologies d’une instance OSPF. Vous pouvez configurer les options de sauvegarde SPF (Shortest-Path-First) suivantes pour remplacer le comportement par défaut :

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

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

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

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

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

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

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

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

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

  • Incluez l’énoncé no-install au niveau de la [edit protocols (ospf | ospf3) backup-spf-options] [edit protocols ospf topology topology-name] 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. Tout saut suivant de sauvegarde calculé pour les autres instances ou topologies OSPF continue d’être installé.

Vous pouvez limiter le calcul des sauts suivant de secours aux chemins en aval, comme défini dans la norme RFC 5286. Vous pouvez spécifier que Junos OS n’utilise que les chemins en aval comme sauts de secours pour les interfaces protégées pour une instance OSPF ou 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 l’équipement de routage calculant 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 ne se traduisent pas par des microloops. Toutefois, votre couverture de sauvegarde peut être inférieure à celle optimale de votre réseau.

Pour limiter le calcul des sauts suivants de secours aux chemins en aval :

  • Incluez l’énoncé downstream-paths-only au niveau de la [edit protocols (ospf | ospf3) backup-spf-options] hiérarchie.[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 topologique :

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

Lors de la configuration d’une interface OSPF pour la protection des liaisons ou des liaisons de nœuds, le calcul SPF (Path-First) le plus court des chemins de secours pour les voisins d’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 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 de secours uniquement pour la topologie par défaut d’OSPFv2 et non pour une topologie configurée. De plus, il n’est pas possible d’utiliser de chemins de secours pour les instances non définies par défaut pour OSPFv2 ou OSPFv3.

Pour configurer un LSP RSVP spécifique en tant que chemin de secours :

  1. Inclure l’énoncé backup au niveau de la [edit protocols mpls labeled-switched-path lsp-name] hiérarchie.
  2. Indiquez 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 protocole RSVP LSP 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.

Exemple : configuration de routes alternatives sans boucle pour OSPF

Cet exemple illustre l’utilisation de la protection des liaisons pour les interfaces activées par OSPF.

Lorsque vous activez la protection des liaisons, Junos OS crée un chemin alternatif vers le saut principal suivant pour toutes les routes de destination qui traversent une interface protégée. Utilisez la protection des liaisons lorsque vous partez du principe qu’une seule liaison peut ne plus être disponible, mais que le nœud voisin reste disponible via une autre interface.

Exigences

Aucune configuration particulière au-delà de l’initialisation de l’équipement n’est requise avant de configurer cet exemple.

Aperçu

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

L’exemple montre deux topologies. L’une est la topologie par défaut, et l’autre est la topologie voix. Pour plus d’informations sur le routage multitopologique, consultez le Multitopology Routing User Guide.

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

Topologie

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

Figure 2 : protection OSPF Link Protection des liaisons OSPF

La configuration rapide cli affiche la configuration de tous les équipements sur la figure 2.

La section #d89e65__d89e783 décrit les étapes relatives à l’équipement R1.

Configuration

Configuration rapide CLI

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

Équipement R1

Équipement R2

Équipement R3

Équipement R4

Équipement R5

Équipement R6

Procédure

Procédure étape par étape

L’exemple suivant nécessite de 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 à Using the CLI Editor in Configuration Mode dans le CLI User Guide.

Pour configurer l’équipement R1 :

  1. Configurez les interfaces de l’équipement.

  2. Étendez la couverture de sauvegarde aux chemins LSP RSVP.

  3. Activez le MPLS sur les interfaces et configurez des LSP de sauvegarde sur l’équipement R3.

  4. Configurez les connexions OSPF, les mesures de liaison et la protection des liaisons.

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

  6. Activez le LDP sur les interfaces.

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

  8. Configurez le processus du protocole de routage (rpd) pour demander une reconnaissance lors de la création d’un nouveau saut de transfert.

    Nous recommandons de configurer l’instruction indirect-next-hop-change-acknowledgements lors de l’utilisation de mécanismes de protection. Cela inclut une protection MPLS RSVP telle que le reroutage rapide (FRR) ainsi qu’une protection contre les liaisons ou nœuds IGP (Interior Gateway Protocol).

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les show interfacescommandes , show protocolset show policy-optionsshow 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é la configuration de l’unité, entrez commit dans le mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification des routes sur l’équipement R1

But

Sur l’unité R1, vérifiez les routes OSPF dans la table de routage.

Action
Sens

Comme prévu, l’équipement R1 dispose de plusieurs routes potentielles vers chaque destination.

Vérifier la couverture de secours

But

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

Action

Vérification des LSP de secours

But

Sur l’unité R1, utilisez la show (ospf | ospf3) backup lsp commande pour vérifier que les LSP sont désignés comme routes de secours pour les routes OSPF.

Action

Vérification des voisins de secours

But

Sur l’unité R1, utilisez la show (ospf | ospf3) backup neighbor commande pour vérifier les voisins via lesquels des sauts directs pour les chemins de secours sont disponibles.

Action

Vérification des calculs SPF

But

Sur l’unité R1, utilisez la show (ospf | ospf3) backup spf detail commande pour vérifier les calculs SPF (Shortest Path-First) OSPF pour les chemins de secours. Pour limiter le débit, la topologie voix est spécifiée dans la commande.

Action

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

Dans un réseau OSPF, une alternative libre en boucle (LFA) est un voisin directement connecté qui fournit des chemins de secours précompilés vers les destinations accessibles via la liaison protégée 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écompilés à l’aide de tunnels LDP créés dynamiquement vers le nœud LFA distant. Le PLR utilise ce chemin de sauvegarde LFA distant en cas d’échec de la liaison principale. L’objectif principal de la LFA à distance est d’augmenter la couverture de secours pour les réseaux OSPF et de fournir une protection pour les réseaux urbains de couche 1.

Les LFA n’offrent pas une couverture de sauvegarde complète pour les réseaux OSPF. Il s’agit d’un échec majeur pour les réseaux Ethernet urbains, souvent façonnés comme des topologies en anneau. Pour surmonter cet échec, les tunnels de sauvegarde RSVP-TE (Resource Reservation Protocol - Traffic Engineering) sont couramment utilisés pour étendre la couverture de secours. Cependant, la majorité des fournisseurs réseau ont déjà implémenté le LDP en tant que protocole de configuration de tunnel MPLS et ne souhaitent pas implémenter le protocole RSVP-TE uniquement pour la couverture de secours. Le LDP met automatiquement en place des tunnels de transport vers toutes les destinations potentielles sur un réseau OSPF et constitue donc le protocole préféré. Le LDP existant mis en œuvre pour la configuration du tunnel MPLS peut être réutilisé pour protéger les réseaux OSPF et les destinations LDP ultérieures, éliminant ainsi le besoin de tunnels de sauvegarde RSVP-TE pour la couverture de secours.

Pour calculer le chemin de secours LFA distant, le protocole OSPF détermine le nœud LFA distant de la manière suivante :

  1. Calcule d’abord le chemin le plus court du routeur adjacent à travers la liaison protégée d’un PLR. Le chemin le plus court utilise d’abord la métrique de liaison entrante au lieu de la mesure de liaison sortante pour atteindre un nœud voisin.

    Il en résulte un ensemble de liens et de nœuds, soit le chemin le plus court entre chaque nœud de branche et le nœud racine.

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

    Il en résulte 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 de branche.

  3. Détermine les nœuds communs à partir des résultats ci-dessus. Ces nœuds sont les LFA distants.

OSPF écoute les étiquettes annoncées pour les routes LDP. Pour chaque routage LDP annoncé, OSPF vérifie s’il contient un saut suivant fourni. Si le routage OSPF correspondant comporte un saut suivant de secours, osPF exécute la stratégie de sauvegarde et ajoute un routage de suivi supplémentaire avec le chemin de commutation d’étiquettes LDP correspondant, le saut suivant comme saut suivant de secours. S’il n’y a pas de sauts suivants de sauvegarde, LDP construit un tunnel LDP dynamique vers le LFA distant, et le LDP établit une adjacence ciblée entre le nœud LFA distant et le nœud PLR. Cette route de secours comporte deux étiquettes LDP. Le label supérieur est la route OSPF, qui indique le chemin de secours entre le PLR et la route LFA distante. Le label inférieur est le chemin de commutation d’étiquettes MPLS LDP qui indique la route permettant d’atteindre la destination finale à partir du LFA distant. Lorsqu’une session LDP tombe en panne et qu’un tunnel distant n’est plus disponible, OSPF modifie tous les itinéraires qui utilisent 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 un label NULL explicite IPv6 à la pile d’étiquettes de la route de suivi. Le système convertit automatiquement le LSP IPv4 en LSP IPv6.

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

  • Les LFA distants distants à plusieurs sauts utilisent des messages hello étendus pour indiquer qu’ils sont prêts à établir une session LDP ciblée. Un LFA distant peut réduire la menace d’usurpation des messages Hello étendus en les filtrant et en acceptant uniquement les sources autorisées par une liste d’accès ou de filtres.

  • Il est nécessaire d’authentifier avec TCP-MD5 toutes les sessions LDP ciblées automatiquement dans le domaine IGP/LDP donné à l’aide de groupes d’application ou d’authentification globale LDP.

  • Par mesure de sécurité supplémentaire, les routeurs de points de terminaison de réparation ou de tunnel distant doivent être affectés à partir d’un ensemble d’adresses qui ne sont pas accessibles depuis l’extérieur du domaine de routage.

Configuration de la sauvegarde LFA à distance sur des tunnels LDP dans un réseau OSPF

L’objectif principal d’un circuit alternatif libre en boucle à distance (LFA) est d’augmenter la couverture de secours pour les routes OSPF et d’offrir une protection spécialement pour les réseaux urbains de couche 1. Le LDP existant implémenté pour la configuration du tunnel MPLS peut être réutilisé pour la protection des réseaux OSPF et des destinations LDP suivantes. Le protocole OSPF crée un tunnel LDP dynamique pour atteindre le nœud LFA distant à partir du point de réparation local (PLR). Le PLR utilise ce chemin de sauvegarde LFA distant en cas d’échec de la liaison principale.

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 une adjacence ciblée LDP ne peut pas être formée sans une interface de bouclage. L’adjacence ciblée LDP est essentielle pour déterminer les chemins de sauvegarde LFA distants.

  2. Assurez-vous que le LFA distant permet la détection asymétrique des voisins distants, c’est-à-dire qu’il doit envoyer régulièrement des messages hello ciblés au routeur qui a initié le voisin distant pour une adjacence ciblée automatique LDP.

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

Pour configurer la sauvegarde LFA à distance sur des tunnels LDP dans un réseau OSPF :

  1. Activez la sauvegarde LFA à distance pour déterminer le saut suivant de secours à l’aide du 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. Indiquez un intervalle de temps pour lequel les sessions LDP ciblées sont conservées même après la panne du nœud LFA distant.

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

  4. Indiquez le nombre maximum de sessions LDP ciblées automatiquement pour optimiser l’utilisation de la mémoire.

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

Exemple : configuration de LFA à distance sur des tunnels LDP dans les réseaux OSPF

Dans un réseau OSPF, une alternative libre en boucle (LFA) est un voisin directement connecté qui fournit des chemins de secours précompilés vers les destinations accessibles via la liaison protégée 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écompilés à l’aide de tunnels LDP créés dynamiquement vers le nœud LFA distant. Le PLR utilise ce chemin de sauvegarde LFA distant en cas d’échec de la liaison principale. L’objectif principal de la LFA à distance est d’augmenter la couverture de secours pour les réseaux OSPF et de fournir une protection pour les réseaux urbains de couche 1. Cet exemple montre comment configurer la LFA distante pour les tunnels LDP dans un réseau OSPF afin d’étendre la protection de sauvegarde.

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écutant sur tous les équipements.

Avant de configurer des tunnels LFA sur LDP distants dans un réseau OSPF, assurez-vous de :

  • LDP est activé sur l’interface de bouclage. Sans interface de bouclage, l’adjacence ciblée LDP ne peut pas être formée. LFA distant ne peut pas être configuré sans l’adjacence ciblée LDP.

  • LFA à distance doit permettre la découverte asymétrique des voisins distants, c’est-à-dire qu’elle doit envoyer régulièrement des hellos ciblés au routeur qui a initié le voisin distant pour l’adjacence ciblée automatique LDP.

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

Aperçu

L’exemple comprend neuf routeurs dans une topologie en anneau. Configurez le protocole OSPF sur les interfaces directement connectées. L’unité R6 est le PLR. Cet exemple vérifie que Junos OS met à jour la table de routage de l’équipement R6 avec les routes de saut suivant LDP comme routage de secours.

Topologie

La figure 3 de la topologie montre que les tunnels LFA sur LDP distants des réseaux OSPF sont configurés sur l’équipement R6.

Figure 3 : Exemple de LFA distant sur des tunnels Example Remote LFA over LDP Tunnels LDP

Configuration

Configuration rapide CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez tous les sauts de ligne, modifiez tous les détails nécessaires pour correspondre à 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 entrez commit du mode de configuration.

R0

R1

R2

R3

R4

R5

R6

R7

R8

Configuration de l’équipement R6

Procédure étape par étape

L’exemple suivant nécessite de 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 à Using the CLI Editor in Configuration Mode dans le CLI User Guide.

Pour configurer l’équipement R6 :

  1. Configurez les interfaces.

  2. Attribuez les adresses de bouclage à l’unité.

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

  4. Activez la sauvegarde LFA à distance qui calcule le saut suivant de secours à l’aide d’un chemin de commutation d’étiquettes LDP dynamique.

  5. Configurez les aspects techniques du trafic et la protection des liaisons pour les interfaces dans la zone OSPF.

  6. Indiquez un intervalle de temps pour lequel les sessions LDP ciblées sont conservées lorsque le LFA distant tombe en panne et spécifiez un nombre maximal de sessions LDP ciblées et automatiquement afin d’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 par paquet de la stratégie de routage de l’instruction de stratégie.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les show interfacescommandes , show protocolset show policy-optionsshow 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é la configuration de l’unité, entrez commit dans le mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification des routes

But

Vérifiez que les routes attendues sont apprises.

Action

Sur l’unité 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.

Sens

La sortie affiche toutes les routes dans la table de routage de l’unité R6.

Vérification des routes LDP

But

Vérifiez les routes LDP ciblées automatiquement.

Action

Dans le mode opérationnel, saisissez la show ldp session auto-targeted detail commande.

Vérification des routes OSPF

But

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

Action

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

Sens

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

Vérification du nœud de chemin de secours désigné

But

Affichez le saut suivant LFA distant déterminé pour une destination donnée.

Action

Dans le mode opérationnel, saisissez la show ospf backup spf results commande.

Sens

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 secours

But

Afficher les voisins de secours pour l’équipement R6

Action

Dans le mode opérationnel, saisissez la show ospf backup neighbor commande.

Sens

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