Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Protection contre la sortie dans les VPN de couche 3

Cette rubrique présente le concept et les composants de la protection contre la sortie dans le VPN de couche 3. Il décrit et fournit des exemples sur la façon de configurer les routeurs protégés, de protection et de réparation locale (PLR).

Protection contre la sortie pour la monodiffusion étiquetée BGP

Lorsque des défaillances de nœuds ou de liaisons réseau se produisent, le rétablissement du service à l’aide de la convergence traditionnelle des tables de routage prend un certain temps. Les procédures de réparation locales peuvent fournir une restauration beaucoup plus rapide en établissant une protection locale aussi proche que possible d’une défaillance. Une protection rapide des nœuds de sortie est disponible pour les services dans lesquels l’unicast étiqueté BGP interconnecte des zones, des niveaux ou des systèmes autonomes (AS) IGP. Si un routeur fournisseur détecte qu’un routeur de sortie (AS ou routeur de bordure de zone) est en panne, il transfère immédiatement le trafic destiné à ce routeur vers un routeur protecteur qui transfère le trafic en aval vers la destination.

Pour fournir une protection contre la sortie pour la monodiffusion étiquetée BGP, le nœud de protection doit créer un état de sauvegarde pour les destinations en aval avant que la défaillance ne se produise. L’idée de base de la solution est que le nœud protecteur construit un état de transfert associé au nœud protégé et relaie les étiquettes MPLS attribuées par le nœud protégé plus en aval jusqu’à la destination finale.

Cette fonctionnalité prend en charge les applications Inter-AS Option C et Seamless MPLS.

Inter-AS Option C : la monodiffusion étiquetée BGP fournit des chemins de commutation d’étiquettes (LSP) de transport de bout en bout en reliant les LSP intra-AS. Les routeurs de limite AS exécutent EBGP vers d’autres routeurs de limite AS afin d’échanger des étiquettes pour les routes de bouclage /32 PE. L’IBGP s’exécute entre le routeur Provider Edge et les routeurs de limite AS au sein de chaque AS. Sur la Figure 1, le trafic va de CE1 à CE2. ASBR1 est le routeur de frontière AS protégé, ASBR2 est le protecteur et l’appareil P1 est le point de réparation locale (PLR). Le chemin principal est choisi de PE1 à PE2 plutôt que ASBR1 et ASBR3. En cas de défaillance d’ASBR1, le routeur P1 détecte la défaillance d’ASBR1 et transfère le trafic à ASBR2, qui fournit un service de secours et transfère le trafic en aval.

Figure 1 : Option C Network topology diagram illustrating connections: CE1 and CE2 connect to PE1 and PE2; P1 to P4 are core routers; ASBR1 to ASBR4 link autonomous systems. d’Inter-AS

MPLS transparent : l’unicast étiqueté BGP fournit des LSP de transport de bout en bout en reliant les LSP intra-zone/niveau. Les routeurs de bordure de zone (ABR) exécutent l’unicast étiqueté BGP vers d’autres ABR pour échanger des étiquettes contre des routes de bouclage /32 PE. Sur la Figure 2, le trafic passe de l’équipement CE1 à l’équipement CE2. ABR1 est l’ABR protégé, ABR2 est le protecteur et T1 est le PLR. Le chemin principal est choisi de PE1 à PE2 sur ABR1 et ABR3. Lorsque ABR1 tombe en panne, le routeur T1 détecte la défaillance ABR1 et transfère le trafic à ABR2, qui fournit un service de secours et transfère le trafic en aval.

Figure 2 : MPLS Network topology diagram showing OSPF routing with areas 0, 1, and 2; includes ABR1-4, PE1-2, T1-6, and CE1-2 routers. transparent

Dans chacune de ces applications, le nœud protégé annonce une route unicast principale étiquetée BGP qui doit être protégée. Lorsque la protection rapide est activée, BGP annonce les routes d’étiquettes avec une adresse spéciale comme saut suivant. Cette adresse spéciale est un identificateur de contexte configuré via l’interface de ligne de commande. Le nœud protégé annonce également l’identificateur de contexte en IGP et une étiquette NULL dans LDP pour l’identificateur de contexte.

Le nœud de sauvegarde annonce des routes unicast de sauvegarde étiquetées BGP pour les routes protégées. Le nœud de protection transfère le trafic vers le nœud de sauvegarde à l’aide des étiquettes annoncées par le nœud de secours.

Le noeud de protection fournit le service de sauvegarde en croisant les étiquettes provenant du noeud protégé et les étiquettes provenant du noeud de secours. Le noeud protecteur transfère le trafic vers le noeud de secours en cas de défaillance du noeud protégé. Le nœud protecteur annonce le même identificateur de contexte dans IGP avec une métrique élevée. De plus, il annonce une étiquette réelle dans LDP pour l’identificateur de contexte. Le nœud protecteur écoute les routes unicast étiquetées BGP annoncées par le nœud protégé et le nœud de secours, et remplit la table d’étiquettes de contexte et la FIB de sauvegarde. Lorsque le trafic avec l’étiquette LDP de contexte réel arrive, la recherche est effectuée dans le contexte d’un nœud protégé. Le nœud de protection fait souvent office de nœud de secours.

Le PLR détecte la défaillance du nœud protégé et transmet le trafic MPLS au nœud de protection. La métrique IGP élevée ainsi que l’étiquette LDP annoncée par le nœud de protection garantissent que le PLR utilise le nœud de protection comme LSP de secours LDP.

Il existe deux types de protection pris en charge : le protecteur colocalisé et le protecteur centralisé. Dans le type colocalisé, le noeud protecteur est également le noeud de secours. Dans le type centralisé, le nœud de sauvegarde est différent du nœud de protection.

configuration de la protection contre la sortie pour BGP étiqueté unicast

Une protection rapide des nœuds de sortie est disponible pour les services dans lesquels l’unicast étiqueté BGP interconnecte des zones, des niveaux ou des AS IGP. Si un routeur fournisseur détecte qu’un routeur de sortie (AS ou routeur de bordure de zone) est en panne, il transfère immédiatement le trafic destiné à ce routeur vers un routeur protecteur qui transfère le trafic en aval vers la destination.

Avant de configurer la protection contre la sortie pour la monodiffusion étiquetée BGP, assurez-vous que tous les routeurs de l’AS ou de la zone exécutent Junos OS 14.1 ou une version ultérieure.

Pour configurer la protection contre la sortie pour la monodiffusion étiquetée BGP :

  1. Ajoutez la configuration suivante au routeur protégé :
  2. Ajoutez la configuration suivante au routeur protecteur :
  3. Ajoutez la configuration suivante au routeur PLR (point de réparation local) :
  4. Exécutez show bgp neighbor sur le routeur protégé pour vérifier que la protection contre la sortie est activée, par exemple :

Voir aussi

Exemple : configuration de la protection contre la sortie pour BGP étiqueté unicast

Cet exemple montre comment configurer la protection unicast étiquetée BGP qui peut être utilisée en cas de défaillance PE dans une topologie Inter-AS Option C.

Exigences

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

  • Routeurs de périphérie multiservice M Series, Plates-formes de routage universelles 5G MX Series ou routeurs centraux T Series

  • Junos OS version 14.1 ou ultérieure

Aperçu

Lorsque des défaillances de nœuds ou de liaisons réseau se produisent, le rétablissement du service à l’aide de la convergence traditionnelle des tables de routage prend un certain temps. Les procédures de réparation locales peuvent fournir une restauration beaucoup plus rapide en établissant une protection locale aussi proche que possible d’une défaillance. Une protection rapide des nœuds de sortie est disponible pour les services dans lesquels l’unicast étiqueté BGP interconnecte des zones, des niveaux ou des systèmes autonomes (AS) IGP. Si un routeur fournisseur détecte qu’un routeur de sortie (AS ou routeur de bordure de zone) est en panne, il transfère immédiatement le trafic destiné à ce routeur vers un routeur protecteur qui transfère le trafic en aval vers la destination.

Cet exemple montre comment configurer la protection contre la sortie unicast étiquetée dans un VPN de couche 3.

Topologie

Dans cet exemple, une topologie Inter-AS Option C est mise en place en configurant deux équipements CE (Customer Edge) et six équipements PE (Service Provider Edge) dans quatre systèmes autonomes. Les appareils CE sont configurés en AS100 et AS101. Les appareils PE sont configurés en AS200 et AS300.

La figure 3 illustre la topologie utilisée dans cet exemple.

Figure 3 : protection contre la sortie d’un VPN Network topology diagram with routers in Autonomous Systems: AS 100 has router R0; AS 200 has R1, R2, R3, R8; AS 300 has R4, R5, R6, R9; AS 101 has R7. Point-to-point links with IPs like 10.2.x.x/30 interconnect routers. Loopback addresses for R0 to R9 are 192.0.2.1 to 192.0.2.10. de couche 3

L’objectif de cet exemple est de protéger le routeur PE R4. La protection contre la sortie est configurée sur les routeurs R4 et R9 afin que le trafic puisse être acheminé via la liaison de secours (R9 à R8) lorsque le routeur R4 (ou la liaison de R5 à R4) tombe en panne. Dans cet exemple, le routeur R4 est le routeur protégé, le routeur R9 est le routeur de protection et le routeur R5 est le point de réparation local (PLR).

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.

Routeur R0

Routeur R1

Routeur R2

Routeur R3

Routeur R4

Routeur R5

Routeur R6

Routeur R7

Routeur R8

Routeur R9

Configuration de la protection contre la sortie dans les VPN de couche 3

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 la protection contre la sortie unicast étiquetée :

  1. Configurez les interfaces de chaque routeur, par exemple :

  2. Configurez l’ID de routeur et le numéro du système autonome (AS) pour chaque routeur, par exemple :

    Dans cet exemple, l’ID du routeur est choisi pour être identique à l’adresse de bouclage configurée sur le routeur.

  3. Configurez les protocoles sur chaque routeur, par exemple :

  4. Configurez les stratégies de routage sur tous les routeurs PE et les routeurs de bordure AS (routeurs R1, R3, R4, R6, R8 et R9), par exemple :

  5. Configurez l’instance de routage VPN sur les routeurs R1 et R6.

    et

  6. Configurez la protection contre la sortie pour le routeur R4, en définissant le routeur R4 comme routeur protégé et le routeur R9 comme protecteur.

    et

Résultats

À partir du mode configuration, confirmez votre configuration en entrant les show interfacescommandes , show routing-options, show protocols, ( show policy-options le cas échéant) et show routing-instances (le cas échéant).

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 le routeur, passez commit en mode de configuration.

Répétez la procédure pour chaque routeur de cet exemple, en utilisant les noms et adresses d’interface appropriés pour chaque routeur.

Vérification

Vérification de l’activation de la protection contre la sortie

But

Vérifiez que la protection contre la sortie est activée sur le routeur protégé, le routeur R4.

Action

Exécutez show bgp neighbor sur le routeur R4 pour vérifier que la protection contre la sortie est activée.

Vérification de l’état de l’ASBR protégé en tant que « primaire »

But

Vérifiez que l’état du routeur de bordure AS protégé, le routeur R4, est « principal ».

Action

Exécutez show mpls context-identifier sur le routeur R4.

Vérification de l’état du protecteur ASBR en tant que « protecteur »

But

Vérifiez que l’état du routeur de bordure AS protecteur, le routeur R9, est « protecteur ».

Action

Exécutez show mpls context-identifier sur le routeur R9.

Voir aussi

Présentation de la protection de sortie pour la protection de périphérie VPN de couche 3

En règle générale, la restauration du service VPN de couche 3 pour les routeurs CE multirésidents dépend du routeur PE (Provider Edge) entrant pour détecter la défaillance de la liaison PE ou du nœud PE sortant et basculer le trafic vers le routeur PE de secours. Pour obtenir une restauration plus rapide, un mécanisme de protection pour le routeur PE peut être utilisé pour effectuer une restauration locale du service immédiatement en cas de défaillance d’un nœud PE de sortie. Ce mécanisme nécessite que le routeur au point de réparation locale (PLR) redirige le trafic VPN vers un routeur PE protecteur pour un reroutage rapide du trafic.

La topologie suivante décrit le concept de protection contre la sortie.

Figure 4 : exemple de topologie pour la protection contre la sortie Network topology diagram with PE routers PE1-PE4, CE routers CE1-CE3, PLR devices, and IP ranges 192.0.2.2/24, 192.0.2.3/24, 192.0.2.1/24 indicating MPLS components.

Dans cette topologie :

Le routeur PE3 agit en tant que protecteur pour les instances ou sous-réseaux de routage VPN de couche 3 PE2.

Les routeurs CE font partie d’un VPN où le routeur CE1 est multihébergé avec le routeur PE1 et le routeur PE2. De même, le routeur CE2 est multihébergé avec les routeurs PE2 et PE3.

Le routeur PE1 peut être à l’origine de l’identificateur de contexte du routeur CE1, tandis que le routeur PE2 est le protecteur de cet identificateur de contexte. De même, PE2 peut être à l’origine de l’identificateur de contexte du routeur CE2, tandis que le routeur PE3 est le protecteur de cet identificateur de contexte.

Le chemin de travail emprunté par le routeur PE4 peut passer par PLR>PE2 pour le routeur CE1 et le routeur CE2. Le chemin de sauvegarde du routeur CE1 passe par PLR>PE1. Le chemin de sauvegarde du routeur CE2 passe par PLR>PE3. Dans des circonstances normales, le trafic circule sur la voie de travail.

Lorsque le routeur PE4 détecte la défaillance d’un nœud ou d’une liaison PE2, le trafic est réacheminé du chemin de travail vers le chemin protégé. Dans le processus de basculement normal, la détection de la défaillance et la récupération dépendent du plan de contrôle et sont donc relativement lentes.

En règle générale, en cas de défaillance d’une liaison ou d’un nœud dans le réseau central, le routeur PE sortant doit s’appuyer sur le routeur PE entrant pour détecter la défaillance et basculer vers le chemin de secours, car aucune option de réparation locale n’est disponible en cas d’échec de sortie.

Pour fournir une solution de réparation locale en cas de défaillance d’une liaison PE ou d’un nœud sortant, un mécanisme appelé protection contre la sortie peut être utilisé pour réparer et rétablir rapidement la connexion. Si la protection contre la sortie est configurée, le routeur PLR détecte la défaillance de la liaison ou du nœud PE2 et redirige le trafic via le routeur de protection PE3 à l’aide du chemin de commutation d’étiquettes (LSP) de secours signalé par LDP. Le routeur PLR utilise des itinéraires alternatifs sans boucle par préfixe pour programmer le saut suivant de secours via le routeur PE3, et le trafic est transféré vers les routeurs CE1 et CE2 à l’aide des chemins alternatifs. Cette restauration est effectuée rapidement après que le routeur PLR a détecté la défaillance du nœud de sortie ou de la liaison PE2 du routeur.

Le mécanisme de double protection peut également être utilisé pour la protection contre la sortie, où les deux routeurs PE peuvent agir simultanément en tant que routeur PE principal et routeur PE protecteur pour leurs routes d’ID de contexte respectives ou leurs sauts suivants.

Fonctions du routeur

Sur la Figure 4, les routeurs suivants remplissent les fonctions suivantes :

Routeur PE protégé

Le PE protégé, PE2, remplit les fonctions suivantes :

  • Met à jour un identificateur de contexte pour le saut suivant BGP pour le préfixe VPN de couche 3.

  • Annonce l’identificateur de contexte au domaine IS-IS.

Routeur Protector PE

Le routeur PE3 protecteur remplit les fonctions suivantes :

  • Annonce l’identificateur de contexte au domaine IS-IS avec une métrique élevée. La métrique IGP élevée (configurable) associée à l’étiquette LDP garantit que le routeur PLR utilise le LSP de secours signalé par LDP en cas de défaillance d’un routeur PE de sortie.

  • Création d’une table d’étiquettes de contexte pour la recherche de route et d’une table de transfert de secours pour le routeur PE protégé (PE2).

    Note:

    Le routeur PE protecteur ne doit pas se trouver sur le chemin de transfert vers le routeur PE principal.

Routeur PLR

Le routeur faisant office de point de réparation local (PLR) remplit les fonctions suivantes :

  • Calcule des itinéraires alternatifs sans boucle par préfixe. Pour que ce calcul fonctionne, la configuration de l’instruction node-link-protection et de l’instruction backup-spf-options per-prefix-calculation est nécessaire au niveau de la [edit protocols isis] hiérarchie.

  • Installe les sauts suivants de sauvegarde pour l’identificateur de contexte via le routeur PE3 (Protector PE).

  • Détecte la défaillance du routeur PE et redirige le trafic LSP de transport vers le protecteur.

Note:

Le routeur PLR doit être directement connecté au routeur de protection (dans ce cas, PE3). Si ce n’est pas le cas, l’itinéraire alternatif sans boucle ne trouve pas le chemin de secours vers le protecteur. Cette limitation est supprimée à partir de la version 13.3 de Junos OS.

Protecteur et modèles de protection

Protector est un nouveau rôle ou une nouvelle fonction pour la restauration de la défaillance d’un nœud PE de sortie. Ce rôle peut être joué par un routeur PE de sortie de secours ou tout autre nœud qui participe au plan de contrôle VPN pour les préfixes VPN qui nécessitent une protection de nœud de sortie. Il existe deux modèles de protection en fonction de l’emplacement et du rôle d’un protecteur :

  • Protecteur colocalisé : dans ce modèle, les configurations du routeur PE de protection et du routeur PE de secours sont effectuées sur le même routeur. Le protecteur est colocalisé avec le routeur PE de secours pour le préfixe protégé et dispose d’une connexion directe au site multirésident à l’origine du préfixe protégé. En cas de défaillance d’un PE de sortie, le protecteur reçoit le trafic du routeur PLR et achemine le trafic vers le site multirésident.

  • Protecteur centralisé : dans ce modèle, le routeur PE protecteur et le routeur PE de secours sont différents. Le protecteur centralisé peut ne pas avoir de connexion directe au site multirésident. En cas de défaillance d’une liaison PE de sortie ou d’un nœud, le protecteur centralisé redirige le trafic vers le routeur PE de sortie de secours avec l’étiquette VPN annoncée pour le routeur PE de sortie de secours qui se charge d’envoyer le trafic vers le site multirésident.

Un réseau peut utiliser l’un ou l’autre des modèles de protection ou une combinaison des deux, selon les besoins.

Dans le cadre d’un scénario spécial de protection des nœuds de sortie, si un routeur est à la fois un protecteur et un PLR, il installe des sauts suivants de secours pour protéger le LSP de transport. En particulier, il n’a pas besoin d’un LSP de dérivation pour une réparation locale.

Dans le modèle de protecteur colocalisé, le PLR ou le protecteur est directement connecté au CE via un courant alternatif de secours, tandis que dans le modèle de protecteur centralisé, le PLR ou le protecteur dispose d’un tunnel MPLS vers le PE de secours. Dans les deux cas, le PLR ou le Protecteur installera un saut suivant de sauvegarde avec une étiquette suivie d’une recherche dans une context label table, c’est-à-dire __context__.mpls.0. En cas de défaillance du nœud de sortie, le PLR ou le Protector bascule le trafic vers ce saut suivant de secours dans PFE. L’étiquette externe (l’étiquette LSP de transport) des paquets est insérée et l’étiquette interne (l’étiquette VPN de couche 3 attribuée par le nœud de sortie) est recherchée dans __context__.mpls.0, ce qui entraîne le transfert des paquets directement vers le CE (dans le modèle de protection colocalisée) ou le PE de secours (dans le modèle de protection centralisée).

Pour plus d’informations sur la protection contre les défaillances PE de sortie, consultez Brouillon Internet-minto-2547-egress-node-fast-protection-00, 2547 Protection rapide contre les défaillances PE de sortie. .

Modèle d’annonce IGP

La disponibilité de la protection contre la sortie est annoncée dans le protocole IGP (Interior Gateway Protocol). Les protocoles d’étiquetage ainsi que le programme CSPF (Constrained Shortest Path First) utilisent ces informations pour assurer la protection contre la sortie.

Pour les VPN de couche 3, les annonces IGP peuvent être des types suivants :

  • Identificateur de contexte en tant que lien de stub (pris en charge dans Junos OS 11.4 R3 et versions ultérieures). Un lien reliant un nœud stub à un nœud de transit est un lien stub.

  • Identificateur de contexte en tant que nœud d’alias stub (pris en charge dans Junos OS 13.3 et versions ultérieures).

  • Identificateur de contexte en tant que nœud proxy stub (pris en charge dans Junos OS 13.3 et versions ultérieures).

Par défaut, c’est le lien stub qui est utilisé. Pour activer la fonctionnalité de réparation de point local (PLR) améliorée, dans laquelle le PLR redirige le trafic de service en cas de défaillance de sortie, configurez un nœud d’alias de stub ou un nœud de proxy de stub comme suit :

Les deux méthodes offrent des avantages différents, en fonction des besoins du déploiement de votre réseau.

Identificateur de contexte en tant que nœud d’alias de stub

Dans la méthode stub alias, l’adresse de point de terminaison LSP possède un nœud de sortie de sauvegarde explicite où la sauvegarde peut être apprise ou configurée sur l’avant-dernier nœud de saut d’un LSP protégé. Avec ce modèle, l’avant-dernier nœud de saut d’un LSP protégé configure le tunnel LSP de contournement pour sauvegarder le nœud de sortie en évitant le nœud de sortie principal. Ce modèle nécessite une mise à niveau de Junos OS au niveau des nœuds principaux, mais il est suffisamment flexible pour prendre en charge toutes les contraintes d’ingénierie de trafic.

Le DPP apprend que l’ID de contexte a un protecteur. Lorsque l’ID de contexte principal tombe en panne, les paquets sont réacheminés vers le protecteur par le biais d’un chemin de sauvegarde préprogrammé. L’ID de contexte et le mappage du protecteur sont configurés ou appris sur le PLR et signalés dans l’IGP par le protecteur. Une table de routage appelée inet.5 sur le PLR fournit les détails configurés ou appris par IGP.

L’IS-IS publie des ID de contexte dans le TED par le biais d’une TLV d’adresse IP. L’IS-IS importe cette TLV dans le TED en tant qu’information étendue. IS-IS annonce les routes TLV du protecteur dans la route inet.5 pour l’ID de contexte, le saut suivant du protocole étant l’ID de routeur du protecteur. Si le TLV du protecteur possède une étiquette, celle-ci est ajoutée à la route dans la table de routage inet.5 pour que LDP puisse l’utiliser.

CSPF prend en compte la TLV de l’adresse IP pour le calcul du point de terminaison de tunnel.

Avec le modèle d’alias de stub, la configuration du LSP protecteur ne nécessite aucune modification dans les nœuds. Cependant, la configuration du LSP de contournement pour la protection des nœuds nécessite des modifications du PHN et du routeur de protection.

Lorsque RSVP configure la dérivation pour la protection de nœud LSP, RSVP effectue également une recherche pour le protecteur si le PLR est l’avant-dernier saut du LSP. Si le protecteur est disponible pour la destination LSP, il utilise CSPF pour calculer un chemin avec une contrainte qui exclut le PE de sortie et configure une destination LSP de contournement vers l’ID de contexte si elle n’est pas déjà configurée. Lors de la configuration d’un LSP de contournement vers l’ID de contexte, le DPP annule toutes les options de protection.

LDP est utile dans le cas où le réseau prend en charge une couverture LFA de 100 %, mais pas une couverture LFA de 100 % par préfixe. LDP configure un chemin de secours avec le protecteur avec l’étiquette de contexte annoncée par le protecteur vers le point de service.

Dans les réseaux où la couverture LFA à 100 % n’est pas disponible, il est utile de disposer de LFA LSP de secours avec des tunnels basés sur RSVP.

À l’état stationnaire, le transfert est le même que sur n’importe quel autre LSP protégé dans le DPP. Dans le protecteur, l'étiquette non NULL qui est annoncée et signalée pour l'ID de contexte a le point de saut suivant de la table vers la table de contexte MPLS, où les étiquettes des homologues sont programmées.

Lors d’une défaillance, le PLR échange l’étiquette de transport avec le LSP de dérivation pour l’ID de contexte ou échange l’étiquette context-label (l’étiquette annoncée par le protecteur pour l’ID de contexte) et envoie l’étiquette de transport à l’adresse de l’interface lo0 du protecteur.

Identificateur de contexte en tant que nœud proxy stub

Identificateur de contexte en tant que nœud proxy stub (pris en charge dans Junos OS 13.3 et versions ultérieures). Un nœud stub est un nœud qui n’apparaît qu’à la fin d’un chemin AS, ce qui signifie qu’il ne fournit pas de service de transit. Dans ce mode, connu sous le nom de mode virtuel ou proxy, l'adresse du point de terminaison LSP est représentée sous la forme d'un nœud avec des liens bidirectionnels, avec le nœud de sortie principal et le nœud de sortie de secours du LSP. Avec cette représentation, l’avant-dernier saut du point de sortie principal LSP peut se comporter comme un PLR en mettant en place un tunnel de dérivation pour sauvegarder la sortie en évitant le nœud de sortie principal. Ce modèle présente l’avantage de ne pas avoir à mettre à niveau Junos OS sur les nœuds centraux et aidera ainsi les opérateurs à déployer cette technologie.

L’ID de contexte est représenté sous la forme d’un nœud dans les bases de données TE (Traffic Engineering) et IGP. L’équipement PE principal annonce le nœud de contexte dans les bases de données IGP et TE. L’équipement PE principal et l’équipement PE protégé prennent en charge un lien vers le nœud de contexte avec une bande passante et une métrique TE. Les autres caractéristiques TE des liaisons TE ne sont pas annoncées par Junos OS.

Dans IS-IS, le routeur PE principal annonce le nœud proxy ainsi que les liens vers le routeur principal et le routeur de protection. Les routeurs principal et de protection annoncent des liens vers le nœud proxy. Le nœud proxy génère les informations suivantes.

  • System ID : code binaire décimal basé sur l’ID de contexte.

  • Host name (Nom d’hôte) : nom du protecteur :ID de contexte

  • ID LSP—<ID système>.00

  • Type de PDU : niveau 2 et niveau 1, selon la configuration

  • Attributs LSP :

    • Surcharge : 1

    • IS_TYPE_L1(0x01) | IS_TYPE_L2(0x02) pour l’unité de distribution d’alimentation de niveau 2

    • IS_TYPE_L1 pour le niveau 1

    • Multizone : non

    • Tous les autres attributs : 0

Le nœud proxy ne contient que la zone, la traduction automatique, le nom d’hôte, l’ID de routeur, les protocoles et les TLV d’accessibilité IS. La zone, la traduction automatique, l’authentification et les protocoles TLV sont les mêmes que sur le serveur principal. Le TLV d’accessibilité du IS contient deux liens appelés Cnode-primary-link et Cnode-protector-link. Les deux liens incluent des TLV TE. Les TLV TE-link-TLV suivants sont annoncés dans les liens de contexte :

  • Interface IPv4 ou adresse voisine

  • Bande passante maximale

  • Métrique TE par défaut

  • Identificateurs de lien (local ou distant)

Valeurs sous-TLV :

  • Bande passante : zéro

  • TE metric : métrique TE maximale

  • Adresse de l’interface : ID de contexte

  • Adresse du voisin du protecteur : ID du routeur du protecteur

  • Adresse du voisin principal : ID de routeur protégé

  • Protecteur d’ID local de liaison - 0x80fffff1

  • Lien ID local principal—0x80fffff2

  • Link Remote-ID Protector - Appris du protecteur

  • Lien entre l’ID distant et le primaire : apprentissage à partir du primaire

Liens PE protégés vers le nœud de contexte (le principal annonce le lien avec les détails suivants) :

  • Bande passante : valeur maximale

  • Mesure TE : 1

  • Interface address (Adresse de l’interface) : ID du routeur

  • Adresse voisine du contexte : ID de contexte

  • Link local-ID to context node : généré automatiquement (similaire à un lien factice)

  • Lier l’ID distant au nœud de contexte : 0x80fffff2

Liens Protector PE vers le nœud de contexte :

  • Le protecteur annonce les liens de transit non numérotés avec la métrique de liaison de routage maximale et la métrique TE maximale et une bande passante nulle vers le nœud de contexte. Les autres caractéristiques de TE ne sont pas annoncées.

Les liens non numérotés sont annoncés avec les attributs suivants :

  • Bande passante : 0

  • TE metric—MAX TE metric (Métrique TE maximale)

  • Interface address (Adresse de l’interface) : ID du routeur

  • Adresse voisine du contexte : ID de contexte

  • Lier l’ID local au nœud de contexte : généré automatiquement (similaire à un lien fictif)

  • Lier l’ID distant au nœud de contexte : 0x80fffff1

Dans RSVP, les changements de comportement concernent uniquement le protecteur et les routeurs principaux. RSVP met fin au LSP et le LSP de contournement vers l’ID de contexte. Si l’ID de contexte est le protecteur, une étiquette non NULL est signalée. Sinon, il sera basé sur la configuration ou le type d’étiquette demandé. RSVP vérifie l’objet de route explicite (ERO) à partir du chemin pour lui-même et l’ID de contexte. RSVP envoie le message Resv avec deux objets RRO (Record Route Object), l’un pour l’ID de contexte et l’autre pour lui-même. Cela simule le nœud de l’avant-dernier saut (PHN) pour effectuer la protection du nœud avec le protecteur du LSP principal pour l’ID de contexte. En tant que contournement requis par le reroutage rapide (FRR), le LSP doit fusionner à nouveau avec le protecteur Contournement de la configuration PHN du LSP vers l’ID de contexte via le protecteur en évitant le primaire.

Le protecteur met également fin au LSP de sauvegarde pour l’ID de contexte afin de maintenir le LSP protégé actif en cas de défaillance jusqu’à ce que le nœud entrant resignale le LSP. Le nouveau LSP est rétabli via le protecteur, mais il n’est pas utilisé pour le trafic de service, car le protocole de service n’utilise pas l’ID de contexte. Le LSP traverse le protecteur même si le primaire se lève. Seule la réoptimisation resignale le LSP via le serveur principal. En mode proxy stub, le contournement du LSP avec contraintes n’est pas pris en charge.

LDP ne peut pas utiliser la méthode proxy stub en raison de la métrique gonflée annoncée dans l’IGP.

En ce qui concerne l’état de transfert, un routeur PE qui protège un ou plusieurs segments connectés à un autre PE est appelé PE protecteur. Un PE protecteur doit connaître l’état de transfert des segments qu’il protège du PE principal protégé.

Pour un segment donné, si le PE protecteur n’est pas directement connecté au périphérique CE associé au segment, il doit également apprendre l’état de transfert à partir d’au moins un PE de secours. Cette situation ne peut se produire que dans le cas d’une protection contre les défaillances PE de sortie.

Un PE protecteur maintient l’état de transfert pour un segment donné dans le contexte du PE principal. Un PE protecteur peut conserver l’état pour un sous-ensemble des segments du PE principal ou pour tous les segments du PE principal.

Exemple : configuration de la protection contre la sortie MPLS pour les services VPN de couche 3

Cet exemple décrit un mécanisme de réparation local permettant de protéger les services VPN de couche 3 contre la défaillance du routeur PE (Provider Edge) sortant dans un scénario où les routeurs CE (Customer Edge) sont multirésidents avec plusieurs routeurs PE.

La terminologie suivante est utilisée dans cet exemple :

  • Routeur PE d’origine : routeur PE avec des instances de routage ou des sous-réseaux protégés qui distribue le routeur VPN de couche 3 principal.

  • Routeur PE de secours : routeur PE qui annonce une route VPN de couche 3 de secours.

  • Routeur Protector PE : routeur qui relie les étiquettes VPN distribuées par le routeur PE d’origine aux étiquettes provenant du routeur PE de secours. Le routeur PE protecteur peut également être un routeur PE de secours.

  • Transport LSP : chemin de commutation d’étiquettes (LSP) signalé par LDP pour les sauts suivants BGP.

  • PLR : routeur faisant office de point de réparation local (PLR) et pouvant rediriger le trafic VPN de couche 3 vers un routeur PE protecteur pour permettre une restauration et un réacheminement rapides.

  • Routes alternatives sans boucles : technologie qui ajoute essentiellement une fonctionnalité de reroutage rapide IP au protocole IGP (Interior Gateway Protocol) en précalculant les routes de secours pour toutes les routes principales de l’IGP. Dans le contexte du présent document, l’IGP est IS-IS.

  • Multihébergement : technologie qui vous permet de connecter un équipement CE à plusieurs routeurs PE. En cas d’échec de la connexion au routeur PE principal, le trafic peut être automatiquement basculé vers le routeur PE de secours.

  • Context identifier (Identificateur de contexte) : adresse IPv4 utilisée pour identifier le préfixe VPN à protéger. L’identificateur est propagé aux routeurs centraux PE et PLR, ce qui permet au routeur PE de sortie protégé de signaler la protection de sortie au routeur PE protecteur.

  • Double protection : mécanisme de protection dans lequel deux routeurs PE peuvent agir simultanément en tant que routeur PE principal et routeur PE protecteur pour leurs routes d’ID de contexte ou leurs sauts suivants respectifs. Par exemple, entre les deux routeurs PE PE1 et PE2, PE1 peut être un routeur PE principal pour l’identificateur de contexte 203.0.113.1 et un protecteur pour l’identificateur de contexte 203.0.113.2 De même, le routeur PE2 peut être un protecteur pour l’identificateur de contexte 203.0.113.1 et un routeur PE principal pour l’identificateur de contexte 203.0.113.2.

Exemple : Configuration de la protection contre la sortie pour les services VPN de couche 3

Cet exemple montre comment configurer la protection contre la sortie pour une restauration rapide des services VPN de couche 3.

Exigences

Cet exemple utilise les composants matériels et logiciels suivants

  • Plates-formes de routage universelles 5G MX Series

  • Les PIC de tunnel ou la configuration du mode Services réseau IP améliorés (à l’aide de l’instruction network-services enhanced-ip au niveau de la [edit chassis] hiérarchie).

  • Junos OS version 11.4R3 ou ultérieure s’exécutant sur les équipements

Avant de commencer :

  • Configurez les interfaces des appareils. Reportez-vous au Guide de configuration des interfaces réseau Junos OS.

  • Configurez les protocoles de routage suivants sur tous les routeurs PE et PLR.

    • MPLS, LSP et LDP. Reportez-vous au Guide de configuration des applications MPLS de Junos OS.

    • BGP et IS-IS. Reportez-vous au Guide de configuration des protocoles de routage Junos OS.

  • Configurez les VPN de couche 3. Reportez-vous au Guide de configuration des VPN Junos OS.

Aperçu

En règle générale, la restauration du service VPN de couche 3, en cas de défaillance du routeur PE de sortie (pour les routeurs CE [Customer Edge] multirésidents), dépend du routeur PE entrant pour détecter la défaillance du nœud PE de sortie et basculer le trafic vers le routeur PE de secours pour les sites CE multirésidents.

Junos OS version 11.4R3 ou ultérieure vous permet de configurer la protection de sortie pour les services VPN de couche 3 afin de protéger les services contre la défaillance du nœud PE de sortie dans un scénario où le site CE est multihébergé avec plusieurs routeurs PE. Ce mécanisme permet d’effectuer une réparation locale immédiatement après la défaillance d’un nœud de sortie. Le routeur faisant office de point de réparation local (PLR) redirige le trafic VPN vers un routeur PE protecteur pour rétablir rapidement le service, obtenant ainsi une protection rapide comparable à celle du reroutage rapide MPLS.

Les instructions utilisées pour configurer la protection contre la sortie sont les suivantes :

  • egress-protection: lorsqu’il est configuré au niveau de la hiérarchie [modifier protocoles mpls], cette instruction spécifie les informations du protecteur et l’identificateur de contexte pour le circuit virtuel de protection de couche 3 et de VPN de périphérie :

    Lorsqu’elle est configurée au niveau , [edit protocols bgp group group-name family inet6-vpn unicast]ou [edit protocols bgp group group-name family iso-vpn unicast] de la [edit protocols bgp group group-name family inet-vpn unicast]hiérarchie, l’instruction egress-protection spécifie l’identificateur de contexte qui active la protection contre la sortie pour les informations d’accessibilité de la couche réseau (NLRI) BGP VPN.

    Lorsqu’elle est configurée au niveau de la [edit routing-instances] hiérarchie, l’instruction egress-protection contient l’identificateur de contexte du routeur PE protégé.

    Cette configuration doit être effectuée uniquement dans le routeur PE principal et est utilisée pour les mises à jour BGP sortantes pour les sauts suivants.

    La configuration de l’instruction context-identifier au niveau de la hiérarchie fournit une granularité de l’ID de contexte VRF au niveau de la [edit routing-instances routing-instance-name] périphérie client pour chaque instance VRF.

  • context-identifier: cette instruction spécifie une adresse IPV4 utilisée pour définir la paire de routeurs PE participant au LSP de protection contre la sortie. L’identificateur de contexte est utilisé pour attribuer un identificateur au routeur Protector PE. L’identificateur est propagé aux autres routeurs PE participant au réseau, ce qui permet au routeur PE de sortie protégé de signaler le LSP de protection contre la sortie au routeur PE protecteur.

Configuration

Configuration rapide de la CLI

Note:

Cet exemple ne montre qu’un exemple de configuration pertinent pour configurer la protection PE de sortie pour les services VPN de couche 3 sur le routeur protégé, PE2, le routeur de protection, PE3 et le routeur PLR.

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.

PE2 (routeur PE protégé)

PE3 (routeur Protector PE)

Routeur PLR

Configuration du routeur PE protégé (PE2)

Procédure étape par étape

Pour configurer le routeur PE protégé, PE2 :

  1. Configurez MPLS sur les interfaces.

  2. Configurez la protection contre la sortie et l’identificateur de contexte.

    Note:

    Le type d’identificateur de contexte doit être défini sur primary.

  3. Configurez la protection contre la sortie pour le NRLI BGP configuré.

    Note:

    L’identificateur de contexte configuré au niveau de la [edit protocols bgp group group-name family inet-vpn] hiérarchie doit correspondre à l’identificateur de contexte configuré au niveau de la [edit protocols mpls] hiérarchie.
    Note:

    La configuration de l’identificateur de contexte au niveau de la [edit routing-instances routing-instance-name] hiérarchie permet d’obtenir une granularité de l’ID de contexte au niveau du VRF CE pour chaque instance VRF (Virtual Routing and Forwarding).

  4. Une fois que vous avez terminé de configurer l’appareil, validez la configuration.

Résultats

Confirmez votre configuration en exécutant la commande show protocols. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Configuration du routeur Protector PE (PE3)

Procédure étape par étape

Pour configurer le routeur PE protecteur, PE3 :

  1. Configurez MPLS sur les interfaces.

  2. Configurez la protection contre la sortie et l’identificateur de contexte.

  3. Configurez les paramètres NRLI du VPN de couche 3 IPv4.

  4. Configurez les options de stratégie de routage.

  5. Une fois que vous avez terminé de configurer l’appareil, validez la configuration.

Résultats

Confirmez votre configuration en exécutant les commandes et show protocols . show policy-options Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Configuration du routeur PLR

Procédure étape par étape

Pour configurer le routeur faisant office de point de réparation local (PLR) :

  1. Configurez MPLS sur les interfaces.

  2. Configurez le calcul par préfixe LFA ainsi que la protection des liaisons.

  3. Configurez LDP pour utiliser la métrique de route IGP (Interior Gateway Protocol) au lieu de la métrique de route LDP par défaut (la métrique de route LDP par défaut est 1).

Résultats

Confirmez votre configuration en exécutant 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 détails de la protection contre la sortie

But

Vérifiez la configuration de la protection contre la sortie.

Action
Signification

Instance indique le nom de l’instance de routage. Type indique le type du VRF. Il peut s’agir de l’un ou l’autre local-vrf ou remote-vrf. RIB (base d’informations de routage) indique la table de routage créée pour la protection des arêtes. Context-Id affiche l’ID de contexte associé au RIB. Route Target Affiche la cible de route associée à l’instance de routage.

Vérification des instances de routage

But

Vérifiez les instances de routage.

Action
Signification

Vrf-edge-protection-id affiche la protection contre la sortie configurée dans le routeur Protector PE avec l’instance de routage.

Vérification du BGP NRLI

But

Vérifiez les détails des informations d’accessibilité de la couche réseau du VPN BGP.

Action
Signification

NLRI configured with egress-protection présente la famille BGP configurée avec la protection contre la sortie. egress-protection NLRI inet-vpn-unicast, keep-import: [remote-vrf] Affiche la stratégie de routage de protection contre la sortie pour le groupe BGP.

Exemple : Configuration de la protection contre la sortie d’un VPN de couche 3 avec RSVP et LDP

Cet exemple montre comment configurer la restauration rapide du service à la sortie d’un VPN de couche 3 lorsque le client est multihébergé auprès du fournisseur de services. En outre, cet exemple inclut une fonctionnalité de réparation de point local (PLR) améliorée, dans laquelle le PLR redirige le trafic de service lors d’une défaillance de sortie.

À partir de la version 13.3 de Junos OS, une fonctionnalité PLR améliorée est disponible, dans laquelle le PLR redirige le trafic de service en cas d’échec de sortie. Dans le cadre de cette amélioration, le routeur PLR n’a plus besoin d’être directement connecté au routeur de protection. Auparavant, si le PLR n’était pas directement connecté au routeur du protecteur, l’itinéraire alternatif sans boucle ne pouvait pas trouver le chemin de secours vers le protecteur.

Exigences

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

Cet exemple nécessite Junos OS version 13.3 ou ultérieure.

Aperçu

Dans cet exemple, les appareils de périphérie client (CE) font partie d’un VPN où l’appareil CE1 est multihébergé avec l’appareil PE2 et l’équipement PE3.

L’équipement PE3 agit en tant que protecteur pour les instances ou les sous-réseaux de routage VPN de couche 3.

L’appareil PE1 est à l’origine de l’identificateur de contexte de l’appareil CE1, l’appareil PE2 est le routeur principal de cet identificateur de contexte, tandis que l’équipement PE3 est le protecteur de cet identificateur de contexte.

L’appareil P1 fait office de point de réparation local (PLR). Ainsi, l’appareil P1 peut rediriger le trafic VPN de couche 3 vers le routeur PE protecteur pour permettre une restauration et un réacheminement rapides.

Le chemin de travail passe par P1>PE2. Le chemin d’accès de secours passe par P1>PE3. Dans des circonstances normales, le trafic circule sur la voie de travail. Lorsqu’une défaillance d’un nœud ou d’une liaison PE2 d’équipement est détectée, le trafic est réacheminé du chemin de travail vers le chemin protégé. Dans le processus de basculement normal, la détection de la défaillance et la récupération dépendent du plan de contrôle et sont donc relativement lentes. En règle générale, en cas de défaillance d’une liaison ou d’un nœud dans le réseau central, le routeur PE sortant doit s’appuyer sur le routeur PE entrant pour détecter la défaillance et basculer vers le chemin de secours, car aucune option de réparation locale n’est disponible en cas d’échec de sortie. Pour fournir une solution de réparation locale en cas de défaillance d’une liaison PE ou d’un nœud sortant, un mécanisme appelé protection contre la sortie est utilisé dans cet exemple pour réparer et rétablir rapidement la connexion. La protection sortante étant configurée, le routeur PLR détecte la défaillance de la liaison ou du nœud PE2 de l’équipement et réachemine le trafic via le chemin de commutation d’étiquettes (LSP) de secours signalé par LDP. Le routeur PLR utilise des itinéraires alternatifs sans boucle par préfixe pour programmer le saut suivant de sauvegarde via l’équipement PE3, et le trafic est transféré vers l’appareil CE2 à l’aide des chemins alternatifs. Cette restauration est effectuée rapidement après que le routeur PLR a détecté la défaillance du nœud de sortie ou de la liaison PE2 de l’appareil. Le mécanisme de double protection peut également être utilisé pour la protection contre la sortie, où les deux routeurs PE peuvent agir simultanément en tant que routeur PE principal et routeur PE protecteur pour leurs routes d’ID de contexte respectives ou leurs sauts suivants.

En plus de la protection contre la sortie, cet exemple illustre une fonction PLR améliorée, dans laquelle le PLR redirige le trafic du service en cas d’échec de sortie. Cette amélioration est prise en charge dans Junos OS version 13.3 et ultérieure. Dans cet exemple, l’appareil P1 (le PLR) est directement connecté à l’appareil PE3 (le protecteur). Une nouvelle instruction de configuration, advertise-mode , vous permet de définir la méthode utilisée par le protocole IGP (Interior Gateway Protocol) pour annoncer la disponibilité de la protection contre la sortie.

Topologie

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

Figure 5 : protection contre la sortie d’un VPN de couche 3 avec RSVP et LDP Network topology diagram showing CE routers connected to PE routers with IP subnets and loopback addresses for MPLS or VPN configurations.

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 CE1

Dispositif CE2

Appareil P1

Appareil PE1

Dispositif PE2

Appareil PE3

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 P1 (le DPP) :

  1. Configurez les interfaces des appareils.

  2. Configurez IS-IS.

    Configurez le calcul par préfixe LFA ainsi que la protection des liaisons de nœud.

  3. Activez MPLS.

  4. Activez RSVP.

  5. Activez LDP.

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’équipement PE1 :

  1. Configurez les interfaces des appareils.

  2. Activez RSVP.

  3. Configurez MPLS.

  4. Configurez IBGP.

  5. Configurez IS-IS.

  6. Activez LDP.

  7. Configurez l’instance de routage.

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

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 leGuide de l’utilisateur de l’interface de ligne de commande.

Pour configurer l’équipement PE2 :

  1. Configurez les interfaces des appareils.

  2. Activez RSVP.

  3. Configurez MPLS.

  4. Configurez IBGP.

  5. Configurez IS-IS.

  6. Activez LDP.

  7. Configurez le numéro AS.

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’équipement PE3 :

  1. Configurez les interfaces des appareils.

  2. Activez RSVP.

  3. Configurez MPLS.

  4. Configurez IBGP.

  5. Configurez IS-IS.

  6. Activez LDP.

  7. Configurez la stratégie de routage.

  8. Configurez le numéro AS.

Résultats

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

Appareil P1

Appareil PE1

Dispositif PE2

Appareil PE3

Si vous avez terminé de configurer les périphériques, entrez dans commit le mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification du noeud de protection

But

Sur le nœud de protection (équipement PE3), vérifiez les informations relatives aux identificateurs de contexte de protection contre la sortie configurés.

Action
Signification

Le périphérique PE3 est le nœud de protection pour deux LSP configurés à partir du périphérique PE1 (172.16.183.55) et du périphérique PE2 (172.16.183.56).

Vérification du noeud principal

But

Sur le nœud principal (équipement PE2), vérifiez les informations relatives aux identificateurs de contexte de protection contre la sortie configurés.

Action
Signification

L’équipement PE2 est le nœud principal.

Vérification de l’itinéraire de l’identificateur de contexte

But

Examinez les informations relatives à l’identificateur de contexte (192.0.2.6).

Action

Vérification de la protection contre la sortie

But

Sur l’appareil PE3, vérifiez les itinéraires dans la table de routage.

Action
Signification

Instance indique le nom de la communauté. Type indique le type du VRF. Il peut s’agir de l’un ou l’autre local-vrf ou remote-vrf. Route Target affiche la cible de route associée à l’instance de routage.

Vérification de l’instance de routage sur l’appareil PE1

But

Sur l’appareil PE1, vérifiez les itinéraires dans la table de routage.

Action

Vérification des prestataires de services linguistiques

But

Sur tous les appareils, vérifiez les informations LSP.

Action

Vérification du BGP NRLI

But

Vérifiez les détails des informations d’accessibilité de la couche réseau du VPN BGP.

Action
Signification

NLRI configured with egress-protection présente la famille BGP configurée avec la protection contre la sortie. egress-protection NLRI inet-vpn-unicast, keep-import: [remote-vrf] Affiche la stratégie de routage de protection contre la sortie pour le groupe BGP.

Vérification de la base de données d’ingénierie du trafic

But

Sur tous les appareils, vérifiez le TED.

Action

Vérification de la base de données IS-IS

But

Sur tous les équipements, consultez la base de données IS-IS.

Action